Neurocrat <·········@one.net.au> writes:
> I've been writing software for several years, mostly in C and C++,
> with a bit of Eiffel, Miranda, Pascal, and a few scripting languages
> acquired along the way. I'd been intending to learn Lisp for a
> while,
I am in the same kind of situation. 14 years Lisp *almost* became my
2nd language after Forth. But no implementation was available back
then on my Commodore 64. I was also intrigued by Smalltalk.
The I worked in C, C++ and Perl. I dare say that I became an expert in
the two first languages; who can claim to have become an expert in
Perl except that handful of person who arrange the Camel's hair? but I
think I became a competent Perl programmer at the very least.
Then I started that huge "Does my favorite language exist" thread in
c.l.misc, c.l.forth and c.l.clos, and early on someone pointed out
that my ideal language may well be Lisp.
So I did what I usually do when I'm serious about learning a language:
I started implementing Tangram, my object-relational mapper (for more
details on the Perl version, see http://www.tangram-persistence.org).
And thus far Lisp just looks great!
This prompts the question: why isn't it much more popular? For
example, why is Perl much more popular? In many respects, Lisp is
"Perl done right". Or rather, Perl is "Lisp done wrong".
Perl is quite a good language, but it's biggest asset is CPAN. It
makes it easy to d/load and install vast amounts of functionality,
even for the clueless newbie.
OTOH, getting relational database connectivity for my Lisp(s) proved
*very* cumbersome.
IMHO a CLAN - Comprehensive Lisp Archive Network - with all the
facilities for *easy* installation of modules - may help Lisp take its
right place.
--
Jean-Louis Leroy
http://users.skynet.be/jll
Jean-Louis Leroy <···@skynet.be> writes:
> And thus far Lisp just looks great!
>
> This prompts the question: why isn't it much more popular? For
> example, why is Perl much more popular? In many respects, Lisp is
> "Perl done right". Or rather, Perl is "Lisp done wrong".
What makes you think that it isn't popular? What _is_ your definition
of popular? Well liked? Widely used? Publically touted as the cat's
meow?
Lisp is the first two of the above. As for the third - well, being
strongly hyped is usually the start of the death knell for a language.
We lisp users and vendors tend to quietly just use it and get a lot
done. There are even those who say that it is of competitive
advantage to keep secret their use of Lisp.
You can look at our website (http://www.franz.com) or for a more
general view of what's available, see http://www.alu.org.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
> What makes you think that it isn't popular? What _is_ your definition
> of popular? Well liked? Widely used? Publically touted as the cat's
> meow?
If it's well liked, it's not well known to be so. If it's widely used,
well, that 'fact' is not widely recognized. AFAIK and by counting job
ads.
Seriously, that kind of statement smells of Cou� method. And Perl
dosn't need a compiler either. Yeah, right <g>
--
Jean-Louis Leroy
http://users.skynet.be/jll
"Jean-Louis Leroy" <···@skynet.be> escribi� en el mensaje
···················@enterprise.newedgeconcept...
> Seriously, that kind of statement smells of Cou� method. And Perl
> dosn't need a compiler either. Yeah, right <g>
Cou�? :-?
Duane Rettig <·····@franz.com> writes:
> Jean-Louis Leroy <···@skynet.be> writes:
>
> > And thus far Lisp just looks great!
> >
> > This prompts the question: why isn't it much more popular? For
> > example, why is Perl much more popular? In many respects, Lisp is
> > "Perl done right". Or rather, Perl is "Lisp done wrong".
>
> What makes you think that it isn't popular? What _is_ your definition
> of popular? Well liked? Widely used? Publically touted as the cat's
> meow?
>
> Lisp is the first two of the above. As for the third - well, being
> strongly hyped is usually the start of the death knell for a language.
> We lisp users and vendors tend to quietly just use it and get a lot
> done. There are even those who say that it is of competitive
> advantage to keep secret their use of Lisp.
No offense, but this all seems needlessly defensive. There's no
reason to stick our heads in the sand and pretend that Lisp is really
popular.
It'd be nice if it were. I've just finished a system upgrade,
wrestling with a bunch of different configuration languages that
should have all been sexp-based, and at this moment no-one wishes Lisp
were more popular more than I.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
Tom Breton <···@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Jean-Louis Leroy <···@skynet.be> writes:
> >
> > > And thus far Lisp just looks great!
> > >
> > > This prompts the question: why isn't it much more popular? For
> > > example, why is Perl much more popular? In many respects, Lisp is
> > > "Perl done right". Or rather, Perl is "Lisp done wrong".
> >
> > What makes you think that it isn't popular? What _is_ your definition
> > of popular? Well liked? Widely used? Publically touted as the cat's
> > meow?
> >
> > Lisp is the first two of the above. As for the third - well, being
> > strongly hyped is usually the start of the death knell for a language.
> > We lisp users and vendors tend to quietly just use it and get a lot
> > done. There are even those who say that it is of competitive
> > advantage to keep secret their use of Lisp.
>
> No offense, but this all seems needlessly defensive. There's no
> reason to stick our heads in the sand and pretend that Lisp is really
> popular.
You'll get no apologies from me on this one. I proudly defend my
favorite language. Not that it needs much defending; it has outlasted
most languages, even through the times in the early 90s when the
naysayers were saying that Lisp was dead. It even lasts through its
biggest threat: those people who say that they love Lisp, but who
just can't program in it because it isn't Popular Enough. It's a
little like the Laurel and Hardy movies, where Stan Laurel would,
after he has made yet another blunder close to the end of the movie,
take the hat or stick and beat himself over the head with it, rather
than risk getting hit with it again by Ollie Hardy. It's a good
comic bit the first time it's seen, but it gets old fast.
To be more pointedly serious, there are only two major complaints
about Lisp that I have ever heard that I take seriously nowadays:
- Too many parentheses (I can't do anything about this fundamental
difference in preference, so I ignore the complaint and enjoy the
beauty of the simplicity in parethesis-oriented syntax).
- The "fact" that Lisp is so unpopular (with _so_ many people
saying it, it _must_ be true, right?)
The rest of people that discover Lisp, tend to love Lisp. That makes
it Popular, in my definition of the term. Very few people _don't_
like Lisp as a language.
> It'd be nice if it were. I've just finished a system upgrade,
> wrestling with a bunch of different configuration languages that
> should have all been sexp-based, and at this moment no-one wishes Lisp
> were more popular more than I.
So start making it more popular by replacing some of those
configuration languages with Lisp. Or, you could use one of Lisp's
greatest strengths, that of writing other languages, and generate
those target langugaes with Lisp source.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
> - Too many parentheses (I can't do anything about this fundamental
> difference in preference, so I ignore the complaint and enjoy the
> beauty of the simplicity in parethesis-oriented syntax).
> - The "fact" that Lisp is so unpopular (with _so_ many people
> saying it, it _must_ be true, right?)
In my case I assumed that Lisp:
1) was slow (in particular I because I believed that lists were the
only available data structure)
2) lacked static typing
WRT (2) I discovered that some sort of typing exists (declare).
WRT (1) I was very surprised to find out that Lisp is not slow, in
particular it seems to beat Perl.
So perhaps it would help if the Lisp community loudly said to the
world that Lisp has evolved too...
--
Jean-Louis Leroy
http://users.skynet.be/jll
* Jean-Louis Leroy <···@skynet.be>
| So perhaps it would help if the Lisp community loudly said to the
| world that Lisp has evolved too...
Sadly, "the world" mostly believes in evolution if you change the
name of the tool, or increment some already ridiculous version
number. Common Lisp doesn't have any meaningful use for a ++ behind
its name, it doesn't have its year of standardization in its name,
either, and it's unclear which version of the language we have.
Case in point: ANSI Common Lisp from 1994 is not Lisp 1.5 from 1960,
but you probably still thought you dealt with 1960's Lisp when you
started to use a modern Common Lisp environment. If you did that,
and you know it's as bogus as it can get, the question is how you
were able to avoid all the information about Lisp's evolution.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum wrote:
>
> * Jean-Louis Leroy <···@skynet.be>
> | So perhaps it would help if the Lisp community loudly said to the
> | world that Lisp has evolved too...
>
> Sadly, "the world" mostly believes in evolution if you change the
> name of the tool, or increment some already ridiculous version
> number. Common Lisp doesn't have any meaningful use for a ++ behind
> its name, it doesn't have its year of standardization in its name,
> either, and it's unclear which version of the language we have.
If that's a problem it's just a matter of a new box (with
an embossed hologram on the side), a new name, and an
air-head press statement.
Introducing Lisp2
Forty years in the making, Lisp2 is a major improvement over its
predecessor, Lisp1.5. New features in this release include:
-o- Java-style garbage collector: end dangling pointer misery
-o- native code compiler: Lisp isn't just interpreted any more
-o- arrays and structures: no need to keep everything in lists
-o- integrated object system: you can even define methods for builtin types
-o- long integers: 64 bits and beyond
-o- Emacs integration: compile without even leaving your editor
-o- macros: smart template expansion makes your code clear AND efficient
-o- <etc>
Erik Naggum <····@naggum.no> writes:
> * Jean-Louis Leroy <···@skynet.be>
> | So perhaps it would help if the Lisp community loudly said to the
> | world that Lisp has evolved too...
>
> Sadly, "the world" mostly believes in evolution if you change the
> name of the tool, or increment some already ridiculous version
> number. Common Lisp doesn't have any meaningful use for a ++ behind
> its name, it doesn't have its year of standardization in its name,
> either, and it's unclear which version of the language we have.
>
> Case in point: ANSI Common Lisp from 1994 is not Lisp 1.5 from 1960,
> but you probably still thought you dealt with 1960's Lisp when you
> started to use a modern Common Lisp environment. If you did that,
> and you know it's as bogus as it can get, the question is how you
> were able to avoid all the information about Lisp's evolution.
Has anyone looked at the recently published, four-volume reference
work, The Handbook of Programming Languages? I inspected these
recently and was surprised to find the following:
1) The volume I, Object Oriented Programming Languages, has chapters
on C++, Java, Eiffel, Ada95, Modula-3. No clos.
2) The volume IV, Functional Programming Languages, covers lisp, but
does it by having chapters on emacs lisp, guile and scheme! There
*is* also a chapter on clos (at the end), but it's separated from the
rest of the object oriented group in vol. I. There is no treatment of
common lisp.
I was very surprised to see the poorly-informed treatement given lisp
in this work.
I found it to be an interesting and readable work in other respects.
--
John M. Adams
>
> 1) The volume I, Object Oriented Programming Languages, has chapters
> on C++, Java, Eiffel, Ada95, Modula-3. No clos.
>
> 2) The volume IV, Functional Programming Languages, covers lisp, but
> does it by having chapters on emacs lisp, guile and scheme! There
> *is* also a chapter on clos (at the end), but it's separated from the
> rest of the object oriented group in vol. I. There is no treatment of
> common lisp.
They try to explain why the did it, but anyway I think the chapter
about common lisp object system is quite ok.
I do not understand why the choose which language. E.g why Modula-3
but not Oberon or Sather, why Python but not Tcl/Tk, I don't remember
what is with Perl, than the talk about Icon which I just have seen
there the first time.
There is no Haskell, Miranda, Dylan or other further developments of
functional languages. So IMO the part of the functional programmin
languages it too much neglected.
Regards
Friedrich
From: Arne Knut Roev
Subject: Re: Lisp - First Impressions
Date:
Message-ID: <Fw7C13.Dqo@online.no>
Friedrich Dominicus <···················@inka.de> wrote:
[snip!]
> There is no Haskell, Miranda, Dylan or other further developments of
> functional languages. So IMO the part of the functional programmin
> languages it too much neglected.
Given what you and Mr Adams are telling us about this work, it might be a
good idea to write the publishers a letter informing them of the fact that
publishing substandard technical literature is rightly considered to be
showing contempt for their customers.
Incidentally, who are the authors of this work, and who are the publishers ?
Just so I'll know to be careful about their other works...
--
Arne Knut Roev <······@online.no> Snail: N-6141 ROVDE, Norway
=
The Gates of Hell shall not prevail:
Darkness now; then Light!
Arne Knut Roev <······@online.no> writes:
> Friedrich Dominicus <···················@inka.de> wrote:
> [snip!]
> > There is no Haskell, Miranda, Dylan or other further developments of
> > functional languages. So IMO the part of the functional programmin
> > languages it too much neglected.
>
> Given what you and Mr Adams are telling us about this work, it might be a
> good idea to write the publishers a letter informing them of the fact that
> publishing substandard technical literature is rightly considered to be
> showing contempt for their customers.
>
> Incidentally, who are the authors of this work, and who are the publishers ?
>
> Just so I'll know to be careful about their other works...
The publisher is Macmillan Technical Publishing and the Editor in
Chief is Peter Salus. The authors are many. In many cases, they are
famous and well respected.
I think the series overall is a useful work. I also agree with an
earlier post that the chapter on clos is good.
I just thought the presentation of lisp was surprisingly retarded
given the work's apparent intent to give a broad, contemporary
presentation. The chances of an interested newcomer getting an
accurate picture of lisp from this work are nil. The first chapter is
an excerpt from the LISP 1.5 programmer's reference manual. Chapter
2-4 cover emacs lisp, scheme and guile. Chapter 5 covers clos.
--
John M. Adams
Jean-Louis Leroy <···@skynet.be> writes:
> WRT (1) I was very surprised to find out that Lisp is not slow, in
> particular it seems to beat Perl.
>
> So perhaps it would help if the Lisp community loudly said to the
> world that Lisp has evolved too...
There's often an assumption that Lisp is interpreted, even though
there have been Lisp compilers since almost the beginning. The
Lisp 1.5 book is about a system that has both an interpreter and
a compiler.
Here's another item. Way back in the 80s I used to use Franz Lisp
on a VAX 750, and it was easy to find cases in which that Lisp,
compiled, was faster than C. You just had to have a high enough
denisty of procedure calls to "local" functions (in the same file,
but needing a declaration too), because the Franz compiler would
then use a more efficient calling sequence, while the C compiler
always used "calls" or "callg" or whatever it was.
The moral of this is that "the efficiency of a language" is
often just a matter of how much effort is put into making the
implementations efficient. The language might make this easier
or harder, but isn't really fast or slow in itself.
-- j
Voice in the desert: Quiet, isn't it, Duane Rettig?
> It even lasts through its
> biggest threat: those people who say that they love Lisp, but who
> just can't program in it because it isn't Popular Enough.
These days, it's almost the only language that I still use.
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
In article <·············@beta.franz.com>, Duane Rettig
<·····@franz.com> wrote:
> To be more pointedly serious, there are only two major complaints
> about Lisp that I have ever heard that I take seriously nowadays:
>
> - Too many parentheses (I can't do anything about this fundamental
> difference in preference, so I ignore the complaint and enjoy the
> beauty of the simplicity in parethesis-oriented syntax).
Maybe there should be a canonical text that explains the
beauty of parentheses and how a good Lisp IDE makes it
a killer feature that greatly amplifies programmer
productivity.
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinh�ft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: ····················@ision.net WWW: http://www.ision.net/
"Duane Rettig" <·····@franz.com> wrote in message
··················@beta.franz.com...
[snip]
> - Too many parentheses (I can't do anything about this fundamental
> difference in preference, so I ignore the complaint and enjoy the
> beauty of the simplicity in parethesis-oriented syntax).
Maybe it's not exaclty hits the point, but when I told by colleagues that
Lisp has *too* many parens I argue that C has the same quantity of rubbish
separators but uniformly sparsed across punctuation symbols.
The idea is to show people that Lisp has as much parens as needed to reflect
code structure explicitly, no less, no more. For instance, let's take a C
code, replace each grouping operator (i.e. ,;[]{}#) with a pair of
parentheses, and expand conditions as if we didn't knew operator precedence.
We'll get some thing like shown below:
(include <stdio.h>)
(include <stdlib.h>)
int main(void)
(
(unsigned char *buf = new unsigned char(1024))
(int length = 1024)
(for ((int i = 0) (i < length) i++)
buf(i)=(char)rand())
(unsigned char (*freq = new unsigned char(256))
(*codes = new unsigned char(256)))
(int (i) (j))
(char tmp)
(for ((i = 0) (i < length) i++)
((freq(i) = 0)
(codes(i) = (char)i)))
(for ((i = 0) (i < length) i++)
freq(buf(i))++)
(for ((i = 0) (i < 255) i++)
for ((j = i + 1) (j < 256) j++)
if (freq(i) < freq(j))
(
(tmp = freq (i))
(freq(i) = freq(j))
(freq(j) = tmp)
(tmp = codes(i))
(codes(i) = codes(j))
(codes(j) = tmp)
))
(for((i = 0) (i<256) i++)
(
(printf("\nfreq: %d" freq(i)))
(if((32 < codes(i)) || (codes(i) < 255))
printf("\nchar: %c" codes(i)))
))
(delete () buf)
(delete () codes)
(delete () freq)
(return 0))
Looks the right way, isn't it? After that, most of people do agree that
parens in Lisp is nothing special but the way to express code nesting right.
--
Eugene.
On Tue, 13 Jun 2000 15:33:12 +0300, "Eugene Zaikonnikov" <······@cit.org.by>
wrote:
> "Duane Rettig" <·····@franz.com> wrote in message
> ··················@beta.franz.com...
> [snip]
> > - Too many parentheses (I can't do anything about this fundamental
> > difference in preference, so I ignore the complaint and enjoy the
> > beauty of the simplicity in parethesis-oriented syntax).
>
> Maybe it's not exaclty hits the point, but when I told by colleagues that
> Lisp has *too* many parens I argue that C has the same quantity of rubbish
> separators but uniformly sparsed across punctuation symbols.
You could also point paren-haters at Lisp-like languages that do offer infix
syntax, eg Dylan.
__Jason
* Duane Rettig wrote:
> It even lasts through its biggest threat: those people who say that
> they love Lisp, but who just can't program in it because it isn't
> Popular Enough. It's a little like the Laurel and Hardy movies,
> where Stan Laurel would, after he has made yet another blunder close
> to the end of the movie, take the hat or stick and beat himself over
> the head with it, rather than risk getting hit with it again by
> Ollie Hardy. It's a good comic bit the first time it's seen, but it
> gets old fast.
Yes, I wish people wouldn't do this. If you want to write stuff in
Lisp, just *do* *it*: we are. If you can write something people
actually want they won't care what language it's in.
> So start making it more popular by replacing some of those
> configuration languages with Lisp. Or, you could use one of Lisp's
> greatest strengths, that of writing other languages, and generate
> those target langugaes with Lisp source.
I wish people would do this kind of thing too. I wonder how many
people have written disk-partition calculating stuff in Lisp?
--tim
On 13 Jun 2000 13:50:22 +0100, Tim Bradshaw <···@cley.com> wrote:
> * Duane Rettig wrote:
> > It even lasts through its biggest threat: those people who say that
> > they love Lisp, but who just can't program in it because it isn't
> > Popular Enough. It's a little like the Laurel and Hardy movies,
[...]
> Yes, I wish people wouldn't do this. If you want to write stuff in
> Lisp, just *do* *it*: we are. If you can write something people
This "I can't use Lisp because it isn't popular" attitude reminds me of TV
commercials. They try to convey an emotional setting that motivates the
potential customer to join the crowd of happy customers so that he too can
live the same lifestyle. Apparently, "mainstream" technologies produce
effects similar to those of commercials.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Voice in the desert: Quiet, isn't it, Paolo Amoroso?
> This "I can't use Lisp because it isn't popular" attitude reminds me of TV
> commercials. They try to convey an emotional setting that motivates the
> potential customer to join the crowd of happy customers so that he too can
> live the same lifestyle. Apparently, "mainstream" technologies produce
> effects similar to those of commercials.
Another aspect: Happy vendors indifferent to the demands of their
consumers. Not every programmer can be a contractor.
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
<URL:http://www.wildcard.demon.co.uk>
Tom Breton <···@world.std.com> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Jean-Louis Leroy <···@skynet.be> writes:
> >
> > > And thus far Lisp just looks great!
> > >
> > > This prompts the question: why isn't it much more popular? For
> > > example, why is Perl much more popular? In many respects, Lisp is
> > > "Perl done right". Or rather, Perl is "Lisp done wrong".
> >
> > What makes you think that it isn't popular? What _is_ your definition
> > of popular? Well liked? Widely used? Publically touted as the cat's
> > meow?
> >
> > Lisp is the first two of the above. As for the third - well, being
> > strongly hyped is usually the start of the death knell for a language.
> > We lisp users and vendors tend to quietly just use it and get a lot
> > done. There are even those who say that it is of competitive
> > advantage to keep secret their use of Lisp.
>
> No offense, but this all seems needlessly defensive. There's no
> reason to stick our heads in the sand and pretend that Lisp is really
> popular.
You'll get no apologies from me on this one. I proudly defend my
favorite language. Not that it needs much defending; it has outlasted
most languages, even through the times in the early 90s when the
naysayers were saying that Lisp was dead. It even lasts through its
biggest threat: those people who say that they love Lisp, but who
just can't program in it because it isn't Popular Enough. It's a
little like the Laurel and Hardy movies, where Stan Laurel would,
after he has made yet another blunder close to the end of the movie,
take the hat or stick and beat himself over the head with it, rather
than risk getting hit with it again by Ollie Hardy. It's a good
comic bit the first time it's seen, but it gets old fast.
To be more pointedly serious, there are only two major complaints
about Lisp that I have ever heard that I take seriously nowadays:
- Too many parentheses (I can't do anything about this fundamental
difference in preference, so I ignore the complaint and enjoy the
beauty of the simplicity in parethesis-oriented syntax).
- The "fact" that Lisp is so unpopular (with _so_ many people
saying it, it _must_ be true, right?)
The rest of people that discover Lisp, tend to love Lisp. That makes
it Popular, in my definition of the term. Very few people _don't_
like Lisp as a language.
> It'd be nice if it were. I've just finished a system upgrade,
> wrestling with a bunch of different configuration languages that
> should have all been sexp-based, and at this moment no-one wishes Lisp
> were more popular more than I.
So start making it more popular by replacing some of those
configuration languages with Lisp. Or, you could use one of Lisp's
greatest strengths, that of writing other languages, and generate
those target langugaes with Lisp source.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Voice in the desert: Quiet, isn't it, Tom Breton?
> No offense, but this all seems needlessly defensive. There's no
> reason to stick our heads in the sand and pretend that Lisp is really
> popular.
Ye Olde Siege Mentality. Today, Java is attacked with the same
arguments once used against Lisp. I find that...ironic.
> It'd be nice if it were. I've just finished a system upgrade,
> wrestling with a bunch of different configuration languages that
> should have all been sexp-based, and at this moment no-one wishes Lisp
> were more popular more than I.
BTDT. Why are we not all using Lisp Machines by now? Politics?
> --
> Tom Breton, http://world.std.com/~tob
> Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
> Some vocal people in cll make frequent, hasty personal attacks, but if
> you killfile them cll becomes usable.
[grin]
This is an automated post written by some Lisp code. ;)
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
Jean-Louis Leroy wrote:
>
> ... who can claim to have become an expert in
> Perl except that handful of person who arrange the Camel's hair?
LMAO ;-)
Whoever chose the camel as a symbol for Perl chose wisely.
> This prompts the question: why isn't it much more popular?
Don't know, but I'll hazard a few guesses:
- The perception that Lisp is mainly useful for experimental
programming, mostly AI related.
- The perception that the tools aren't up to the job of producing small,
fast executables with full GUI support that today's users expect.
- The perception that experienced Lisp programmers are few and far
between.
- Not enough students graduating with knowledge of Lisp.
Here in Australia, Lisp doesn't seem to be very popular. Whether that's
because it isn't widely used or whether, as Erik Naggum suggests, the
number of job advertisements doesn't reflect the true popularity of Lisp
-- I can't say.
Neurocrat <·········@one.net.au> writes:
> - Not enough students graduating with knowledge of Lisp.
add to that:
- an impression that lisp is something used by oldfashioned
professors in universities.
Yes, I got that one presented the other day. Somebody told me that
they thought we were 'oldfashioned' to use lisp (and their favourite
is java, I think, which _I_ consider hopelessly oldfashioned, at heart
java doesn't seem to be much more than Simula anno 1967).
While some universities actually teach lisp, they tend to use C++ for
"real programming" and java for all the hyped stuff ("e-commerce"
and "business objects" and <insert your favourite dot-com-buzzword>).
--
(espen)
Voice in the desert: Quiet, isn't it, Espen Vestre?
> Yes, I got that one presented the other day. Somebody told me that
> they thought we were 'oldfashioned' to use lisp (and their favourite
> is java, I think, which _I_ consider hopelessly oldfashioned, at heart
> java doesn't seem to be much more than Simula anno 1967).
As Alan Kay put it, "Java and C++ make you think that the new ideas
are like the old ones. Java is the most distressing thing to hit
computing since MS-DOS."
How many programmers today even remember Simula? A few of us here,
certainly, but as you say...
> While some universities actually teach lisp, they tend to use C++ for
> "real programming" and java for all the hyped stuff ("e-commerce"
> and "business objects" and <insert your favourite dot-com-buzzword>).
I feel like I live in age where I'm one of the few living people who
can read books. My computer related bookshelves are on two shelves,
one of which may be taxing (Z80/68K assembler, Forth, C/C++, basic CS)
but vaguely familiar to most programmers. The second shelf is for
Lisp, FP, and Smalltalk books. Mostly Lisp. Where I live, it's rare to
find any of them in bookshops. The last one was SICP, a few years ago.
This is computing's Dark Age. To put things into perspective:
http://www.infosecuritymag.com/apr2000/cryptorhythms.htm
So perhaps we're not doing so badly. It's just the spirit of the age.
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
Martin Rodgers <···@thiswildcardaddressintentiallyleftmunged.demon.co.uk> writes:
> I feel like I live in age where I'm one of the few living people who
> can read books. My computer related bookshelves are on two shelves,
> one of which may be taxing (Z80/68K assembler, Forth, C/C++, basic CS)
> but vaguely familiar to most programmers. The second shelf is for
> Lisp, FP, and Smalltalk books. Mostly Lisp. Where I live, it's rare to
> find any of them in bookshops. The last one was SICP, a few years ago.
To judge by your email address you're in the UK - may I ask where?
Here in Cambridge I can find a fair few - I've seen SICP, ANSI Common
Lisp and Lisp in Small Pieces recently. A couple of months back I was
in London and wandered around bookshops for a while and found PAIP and
CLTL2. So, nothing to compare with the acreage devoted to Java and
C++, but not utter bleakness either.
I also have the general impression that the shelf space devoted to
more "obscure" programming languages is increasing, slowly, so maybe
things are getting better.
Optimistically Yours,
Michael
(Random aside: all the books I listed above are really very good;
maybe when one's hunting for lisp books you may not have much choice,
but if you're choosing between books of the quality of SICP or PAIP,
do you care?)
--
This makes it possible to pass complex object hierarchies to a C
coder who thinks computer science has made no worthwhile
advancements since the invention of the pointer.
-- Gordon McMillan, 30 Jul 1998
Voice in the desert: Quiet, isn't it, Michael Hudson?
> To judge by your email address you're in the UK - may I ask where?
South London. My local bookshops are in Croydon and Streatham, the
biggest and best of which is Waterstones. Back in the days when it was
Websters, mid-80s, there was a much wider selection of books.
Today it's almost all "howto" books, Java, C++, HTML. If/when those
nice O'Reilly people publish a "Lisp in a Nutshell" book, I'd say
things are looking better. If anyone would like to co-author such a
book, I'm more than available.
> Here in Cambridge I can find a fair few - I've seen SICP, ANSI Common
> Lisp and Lisp in Small Pieces recently. A couple of months back I was
> in London and wandered around bookshops for a while and found PAIP and
> CLTL2. So, nothing to compare with the acreage devoted to Java and
> C++, but not utter bleakness either.
Central London? Sure, the big shops like Foyle's are excellent. I used
to find many wonderful books there. The last one of W&H 3rd ed, which
should give you some idea when I was last in the city.
Most technical people I know just pop into their local PCWorld. No
doubt I know the wrong technical people, which kind of proves my
point. They tend to be "mainstream" coders.
All of which is purely anecdotal. YMMV, and probably does.
> I also have the general impression that the shelf space devoted to
> more "obscure" programming languages is increasing, slowly, so maybe
> things are getting better.
I hope it is. I found the computer graphics "bible" in my local
Waterstones last year.
> Optimistically Yours,
> Michael
>
> (Random aside: all the books I listed above are really very good;
> maybe when one's hunting for lisp books you may not have much choice,
> but if you're choosing between books of the quality of SICP or PAIP,
> do you care?)
I've had to order most technical books for the last 10 years. For the
last 5 years, it's looked even worse. Perhaps that's because I've had
more book recommendations recently, but the changing nature of the
shelves must surely play a significant role.
It's even more important for anyone who _browses_ for interesting
books. You and I may have a pretty good idea what we're looking for,
but I remember how I bought my first Lisp book - I stumbled across a
copy of W&H, just before the 2nd ed was published. I first read about
Lisp in the Aug 1979 Lisp issue of Byte (borrowed from a friend) and a
review of muLisp in the Nov 1980 issue of Practical Computing (I still
have it).
So my first impressions are about two decades old. It was another 5
years before I got to do more than read about it, but the deluged of
info about other languages helped me appreciate the power of Lisp.
Today there's an info monoculture, thanks to big marketing hype for a
small number of languages. OTOH, a healthy counter culture also
exists, mainly focused around Linux and other Open Source projects.
This makes Lisp accessible to more people than ever before.
The question is, do you feel adventurous? I certainly do.
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
<URL:http://www.wildcard.demon.co.uk>
Michael Hudson <·····@cam.ac.uk> writes:
> I also have the general impression that the shelf space devoted to
> more "obscure" programming languages is increasing, slowly, so maybe
> things are getting better.
I have the same impression. Even (or perhaps especially) out here in
the colonies (Sydney, Aus), there's a fairly wide selection of
"obscure" or "alternative" reading material available. In my uni
bookshop, nestled in among the Teach Yourself [Java, C++, HTML, XML,
NextBigThing] in 24 hours, you'll find books on Eiffel, Blue, Lisp,
Scheme, Python, Prolog ... just about anything. I don't know how
popular these books are among the students, but I know that in
commercial development shops, C++, Delphi and VB (on Windows) still
account for a huge proportion of the jobs.
A few years ago I worked in a book shop while studying. I remember a
strange little gnome-like man with an elvish beard, twinkling eyes and
a strange grin coming in out of the rain to ask about some kooky
little thing called Linux - 6CDs for $6 at a time when Windows 95 was
selling for $159. None of us knew what he was on about, but we managed
to track it down for him eventually.
If somebody had told me back in '95 that, within three years, this
thing called Leenooks/Lyenucks/Linnix would account for almost half of
all technical book sales, I'd have thought they were crazy. So who
knows what the next 5 years will bring?
Neurocrat <·········@one.net.au> writes:
> Michael Hudson <·····@cam.ac.uk> writes:
>
> > I also have the general impression that the shelf space devoted to
> > more "obscure" programming languages is increasing, slowly, so maybe
> > things are getting better.
Well, maybe. But things used to be much better.
What's happened is that the "winners" (C++, VB, Java, Windows, Linux)
have pretty much taken over, with everything else much more
marginalized than it was even 5 years ago.
Or so it seems to me.
> I have the same impression. Even (or perhaps especially) out here in
> the colonies (Sydney, Aus), there's a fairly wide selection of
> "obscure" or "alternative" reading material available. In my uni
> bookshop, nestled in among the Teach Yourself [Java, C++, HTML, XML,
> NextBigThing] in 24 hours, you'll find books on Eiffel, Blue, Lisp,
> Scheme, Python, Prolog ... just about anything.
That used to be common.
Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
> Neurocrat <·········@one.net.au> writes:
>
> > Michael Hudson <·····@cam.ac.uk> writes:
> >
> > > I also have the general impression that the shelf space devoted to
> > > more "obscure" programming languages is increasing, slowly, so maybe
> > > things are getting better.
>
> Well, maybe. But things used to be much better.
>
> What's happened is that the "winners" (C++, VB, Java, Windows, Linux)
> have pretty much taken over, with everything else much more
> marginalized than it was even 5 years ago.
>
> Or so it seems to me.
Well fair enough. I'm only 21, so my experience is only of the last
couple of years. I was thinking in months. In particular, Python
seems to be elbowing it's way into the mainstream, and whether you
think this a good thing or not (I do), the more mainstream languages
there are, the more broad-minded the corporate mindset is likely to
get; saying "you can't use that, it's not C++" sounds less inherently
ridiculuous than "you can't use that it's not C++, Java, Perl, Python,
Visual Basic or Delphi" (or at least I hope so).
Cheers,
M.
--
Academic politics is the most vicious and bitter form of politics,
because the stakes are so low. -- Wallace Sayre
Centuries ago, Nostradamus foresaw a time when Jeff Dalton would say:
>Neurocrat <·········@one.net.au> writes:
>
>> Michael Hudson <·····@cam.ac.uk> writes:
>>
>> > I also have the general impression that the shelf space devoted to
>> > more "obscure" programming languages is increasing, slowly, so maybe
>> > things are getting better.
>
>Well, maybe. But things used to be much better.
>
>What's happened is that the "winners" (C++, VB, Java, Windows, Linux)
>have pretty much taken over, with everything else much more
>marginalized than it was even 5 years ago.
>
>Or so it seems to me.
On the other hand, there are now a good dozen Common Lisp-based
projects on SourceForge, where there was hit-and-miss activity going
on before.
And there are active efforts going on with various "Schemely" systems.
--
·····@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/lisp.html>
I would rather be in the back of a car then a cdr.
-- Blackboard in 6.011 area
Voice in the desert: Quiet, isn't it, Neurocrat?
> but I know that in
> commercial development shops, C++, Delphi and VB (on Windows) still
> account for a huge proportion of the jobs.
I bet Cobol accounts (pun intended) for even more. ;)
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
<URL:http://www.wildcard.demon.co.uk>
Voice in the desert: Quiet, isn't it, Michael Hudson?
> To judge by your email address you're in the UK - may I ask where?
South London. My local bookshops are in Croydon and Streatham, the
biggest and best of which is Waterstones. Back in the days when it was
Websters, mid-80s, there was a much wider selection of books.
Today it's almost all "howto" books, Java, C++, HTML. If/when those
nice O'Reilly people publish a "Lisp in a Nutshell" book, I'd say
things are looking better. If anyone would like to co-author such a
book, I'm more than available.
> Here in Cambridge I can find a fair few - I've seen SICP, ANSI Common
> Lisp and Lisp in Small Pieces recently. A couple of months back I was
> in London and wandered around bookshops for a while and found PAIP and
> CLTL2. So, nothing to compare with the acreage devoted to Java and
> C++, but not utter bleakness either.
Central London? Sure, the big shops like Foyle's are excellent. I used
to find many wonderful books there. The last one of W&H 3rd ed, which
should give you some idea when I was last in the city.
Most technical people I know just pop into their local PCWorld. No
doubt I know the wrong technical people, which kind of proves my
point. They tend to be "mainstream" coders.
All of which is purely anecdotal. YMMV, and probably does.
> I also have the general impression that the shelf space devoted to
> more "obscure" programming languages is increasing, slowly, so maybe
> things are getting better.
I hope it is. I found the computer graphics "bible" in my local
Waterstones last year.
> Optimistically Yours,
> Michael
>
> (Random aside: all the books I listed above are really very good;
> maybe when one's hunting for lisp books you may not have much choice,
> but if you're choosing between books of the quality of SICP or PAIP,
> do you care?)
I've had to order most technical books for the last 10 years. For the
last 5 years, it's looked even worse. Perhaps that's because I've had
more book recommendations recently, but the changing nature of the
shelves must surely play a significant role.
It's even more important for anyone who _browses_ for interesting
books. You and I may have a pretty good idea what we're looking for,
but I remember how I bought my first Lisp book - I stumbled across a
copy of W&H, just before the 2nd ed was published. I first read about
Lisp in the Aug 1979 Lisp issue of Byte (borrowed from a friend) and a
review of muLisp in the Nov 1980 issue of Practical Computing (I still
have it).
So my first impressions are about two decades old. It was another 5
years before I got to do more than read about it, but the deluged of
info about other languages helped me appreciate the power of Lisp.
Today there's an info monoculture, thanks to big marketing hype for a
small number of languages. OTOH, a healthy counter culture also
exists, mainly focused around Linux and other Open Source projects.
This makes Lisp accessible to more people than ever before.
The question is, do you feel adventurous? I certainly do.
--
Email address intentially munged | You can never browse enough
will write code that writes code that writes code for food
<URL:http://www.wildcard.demon.co.uk>
> > (Random aside: all the books I listed above are really very good;
> > maybe when one's hunting for lisp books you may not have much choice,
> > but if you're choosing between books of the quality of SICP or PAIP,
> > do you care?)
>
> I've had to order most technical books for the last 10 years. For the
> last 5 years, it's looked even worse. Perhaps that's because I've had
> more book recommendations recently, but the changing nature of the
> shelves must surely play a significant role.
In the US, a Borders I went to before I moved did fairly well; even
though 60%+ of the computer related bookshelves were filled with the
"Learn to Program ... in 21 Days" variety- or even worse, MCSE
training guides, they still had a shelf of real CS books- and after
some hesitation they started stocking Knuth's TAOCP series. As I
recall they had W&H and the Aluminim Book also.
Unbelievably, the clerk behind the counter actually knew how to search
for the Knuth books, order them, AND let me know when they came in.
Gregm
Martin Rodgers wrote:
+---------------
| How many programmers today even remember Simula?
+---------------
Or circa-1970 POOMAS (POOr MAn's Simula)? A set of BLISS macros (written
at CMU) that let you create/manipulate Simula-style objects and threads
in BLISS, using the builtin BLISS co-routine call "EXCHJ" for threading.
Years later, Bakul Shah & I ported a POOMAS subset to C ["A Simple Simulation
Toolkit in C", USENIX 1984], using setjmp/longjmp instead of EXCHJ, and
I've have been carrying it around with me ever since, using it for small
one-off discrete event simulation tasks.
So I guess I've been doing "object-oriented programming" for 30 years, eh?
Hmmm...
+---------------
| I feel like I live in age where I'm one of the few living people who
| can read books. ... This is computing's Dark Age.
+---------------
Similar sentiments may be found in Rob Pike talk "Systems Software Research
is Irrelevant" <URL:http://cm.bell-labs.com/cm/cs/who/rob/utah2000.ps>.
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
In article <·················@one.net.au>, Neurocrat
<·········@one.net.au> wrote:
> Don't know, but I'll hazard a few guesses:
>
> - The perception that Lisp is mainly useful for experimental
> programming, mostly AI related.
>
> - The perception that the tools aren't up to the job of producing small,
> fast executables with full GUI support that today's users expect.
>
> - The perception that experienced Lisp programmers are few and far
> between.
The existence of several companies selling Common Lisp systems and
of several free versions might give an indication
that some people are still using it. Several times I heard
that companies are not willing to tell that they are
using Lisp or Lisp-based software - it gives them
a competetive advantage. The few available studies are
indicating a *huge* productivity advantage for Lisp
compared to other programming languages - and I guess people
who can read know what to do.
> Here in Australia, Lisp doesn't seem to be very popular. Whether that's
> because it isn't widely used or whether, as Erik Naggum suggests, the
> number of job advertisements doesn't reflect the true popularity of Lisp
> -- I can't say.
Hey, Memetrics in Sydney is looking for Lisp programmers.
http://www.memetrics.com/employment_developers.htm
There is a mailing list for Lisp jobs where they recently
were looking for Lisp programmers.
--
Rainer Joswig, BU Partner,
ISION Internet AG, Steinh�ft 9, 20459 Hamburg, Germany
Tel: +49 40 3070 2950, Fax: +49 40 3070 2999
Email: ····················@ision.net WWW: http://www.ision.net/
In article <·················@one.net.au>,
Neurocrat <·········@one.net.au> wrote:
>Jean-Louis Leroy wrote:
>>
>LMAO ;-)
>Whoever chose the camel as a symbol for Perl chose wisely.
>
The camel is a very useful critter in the desert. It also smells
bad.
>> This prompts the question: why isn't it much more popular?
>
>Don't know, but I'll hazard a few guesses:
>
>- The perception that Lisp is mainly useful for experimental
>programming, mostly AI related.
>
I don't think this is correct. I think people think that Lisp is
good for AI programming (which it is), and assume somehow that AI
programming is a distinct field like accounting or number-crunching.
My experience is that AI programming is at least a bit of everything
else. I don't think there is anywhere near as strong a feeling
that Lisp is good for experimental programming. (Maybe Smalltalk
is perceived in that role.)
>- The perception that the tools aren't up to the job of producing small,
>fast executables with full GUI support that today's users expect.
>
The common wisdom is that Lisp is big and slow. The interesting thing
is that Lisp grew while becoming svelte. There seems to have been
some reasons that Lisp had to be at least X big and Y slow, but
now X and Y are small numbers relative to all the bloatware out there.
To put it another way: Lisp was big and slow. It has grown and
become somewhat faster, but it still tends to do low-level stuff slower
than a good C/C++ implementation. Thing is, everything else has grown
much faster, and how micro-efficient code is has become less and less
important.
>- The perception that experienced Lisp programmers are few and far
>between.
>
Yup. There's also the lack of Lisp programmer ads.
>- Not enough students graduating with knowledge of Lisp.
>
They try to avoid Lisp, because Lisp is dead and there's no jobs.
I've observed that behavior. Pity about that.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) writes:
> In article <·················@one.net.au>,
> Neurocrat <·········@one.net.au> wrote:
[snipped speculation about why Lisp isn't more popular]
> They try to avoid Lisp, because Lisp is dead and there's no jobs.
> I've observed that behavior. Pity about that.
Maybe you've observed that behaviour so many times you you now expect
it every time? I thought this might happen. Evidently the "p" word is
a risky subject around here.
In my case you're as off the mark as you could be (as I mentioned in
the first article in this thread).
I don't much care who else is using Lisp, or whether there are many
Lisp jobs advertised in the newspapers. I'll continue to use it for
pleasure or for pay (hopefully but not necessarily both) because,
after a few days of reading Winston & Horn, and Peter Norvig's PAIP,
my first impression is that it's the language I need. I find it
difficult to understand why a language so rich and potent should be
neglected (somewhat) in favour of languages with nowhere near the
expressive power or elegance.
The comments you responded to above were idle speculations about why
Lisp isn't more popular than it is. There's quite a difference between
wondering why it isn't more popular and wishing it were more
popular. A greater leap still to the decision not to use it because
it's not more popular.
I've many times argued your perspective against the attitude you
ascribe to me. It's irritating enough to argue it with other people,
but to hear it attributed to oneself is too much to take ;-)
Cheers,
Patrick.
On 17 Jun 2000 20:58:12 +1000, Neurocrat <·········@one.net.au> wrote:
>popular. A greater leap still to the decision not to use it because
>it's not more popular.
Dylan is even less popular than Lisp. I'm presently using Smalltalk and am
considering moving to Lisp or Dylan. There are a lot of advantages of each
of them, but I don't really understand most of those advantages. Besides
those two languages, the other option I'm considering is to just keep using
Smalltalk. I assume Lisp and Dylan have most of Smalltalk's features, but
some of them might not be as elegant. Such as the closure syntax, which lets
you combine multiple and/or nested closures on one line of code without
obfuscating it.
Besides the question of which language is better, an even bigger question
might be which development environment is better. Without taking the
language into account, is Functional Developer as good as LispWorks? Are
there any other development environments I should consider, assuming Allegro
is out of my price range?
-- Eric S.
e 4 5 5 @ y a h o o . c o m wrote in message
<··································@4ax.com>...
>On 17 Jun 2000 20:58:12 +1000, Neurocrat <·········@one.net.au> wrote:
>
>>popular. A greater leap still to the decision not to use it because
>>it's not more popular.
>
>Dylan is even less popular than Lisp. I'm presently using Smalltalk and am
>considering moving to Lisp or Dylan. There are a lot of advantages of each
>of them, but I don't really understand most of those advantages. Besides
>those two languages, the other option I'm considering is to just keep using
>Smalltalk. I assume Lisp and Dylan have most of Smalltalk's features, but
>some of them might not be as elegant. Such as the closure syntax, which
lets
>you combine multiple and/or nested closures on one line of code without
>obfuscating it.
Besides popularity, there other other trade-offs between Lisp and
Dylan. If you want to be able to deliver DLL's, for example, Dylan's
the right choice.
>Besides the question of which language is better, an even bigger question
>might be which development environment is better. Without taking the
>language into account, is Functional Developer as good as LispWorks? Are
>there any other development environments I should consider, assuming
Allegro
>is out of my price range?
Disclaimer 1: I worked at Harlequin on Dylan.
Disclaimer 2: Yeah, yeah, so Smalltalk (along with Interlisp) is one
of the great progenitor languages and environments. I still think
Smalltalk environments are very dated and actually pretty clunky.
So...
I think the LispWorks environment basically sucks, although the
interactivity support in it is as good as in any other Lisp environment.
I think the Functional Dylan environment (nee Harlequin Dylan) is
probably one of the really good environments you can find for
any programming language. The code produced by both LispWorks
and by Functional Dylan is really pretty damned good.
On Sat, 17 Jun 2000 23:25:03 GMT, "Scott McKay" <···@mediaone.net> wrote:
>I think the LispWorks environment basically sucks, although the
>interactivity support in it is as good as in any other Lisp environment.
>I think the Functional Dylan environment (nee Harlequin Dylan) is
>probably one of the really good environments you can find for
>any programming language. The code produced by both LispWorks
>and by Functional Dylan is really pretty damned good.
An example would be very helpful, of one of the ways LispWorks sucks, and/or
one of the ways Functional beats it.
Does Functional Objects have a lot of good programmers working full time on
Functional Developer? Or is it more a matter of having inherited it from
Harlequin and having a few programmers continue to maintain it?
To get started with it, is the free version enough, or is it better to spend
the money to get the various extras?
-- Eric S.
"e 4 5 5 @ y a h o o . c o m" wrote:
>
> On Sat, 17 Jun 2000 23:25:03 GMT, "Scott McKay" <···@mediaone.net> wrote:
>
> >I think the LispWorks environment basically sucks, although the
> >interactivity support in it is as good as in any other Lisp environment.
> >I think the Functional Dylan environment (nee Harlequin Dylan) is
> >probably one of the really good environments you can find for
> >any programming language. The code produced by both LispWorks
> >and by Functional Dylan is really pretty damned good.
>
> An example would be very helpful, of one of the ways LispWorks sucks, and/or
> one of the ways Functional beats it.
I'm not very familiar with LispWorks, but one of the things that
FunDev does a lot better than MCL is stepping through source
code a line at a time. The support for this in Harlequin Dylan 1.x
had some problems but it's quite good in FunDev 2.0.
> Does Functional Objects have a lot of good programmers working full time on
> Functional Developer? Or is it more a matter of having inherited it from
> Harlequin and having a few programmers continue to maintain it?
They are doing more than just maintaining it. They've already
done a lot of work on porting to other platforms. Lots of bugs
have been fixed too, notably in DUIM.
> To get started with it, is the free version enough, or is it better to spend
> the money to get the various extras?
You can download the full version for a 30 day trial period if
you just want to evaluate it.
Scott McKay wrote:
> Besides popularity, there other other trade-offs between Lisp and
> Dylan. If you want to be able to deliver DLL's, for example, Dylan's
> the right choice.
I've never actually done it, but my Lispworks manual tells me that I can
deliver DLL's if I want to. I think this was one of the new features in
version 4.1.
Arthur Lemmens
········@visi.com (David Thornley) writes:
> The common wisdom is that Lisp is big and slow. The interesting thing
> is that Lisp grew while becoming svelte. There seems to have been
> some reasons that Lisp had to be at least X big and Y slow, but
> now X and Y are small numbers relative to all the bloatware out there.
>
> To put it another way: Lisp was big and slow. It has grown and
> become somewhat faster, but it still tends to do low-level stuff slower
> than a good C/C++ implementation. Thing is, everything else has grown
> much faster, and how micro-efficient code is has become less and less
> important.
Another mechanism at work here is the growing complexity of all
programs, so that even "small" end-user applications are now quite
complex beasts. Since you need some advanced machinery to tame such
beasts, nearly all non-trivial applications now contain all of the
stuff that CL contains out of the box (things like GC, advanced
condition handling, large utility libraries, bignum arithmetic (=>
cryptograpy), advanced introspective OO systems, object serialization,
run-time patching and debugging aids, etc.), with the small difference
that the implementations in a CL system were designed, implemented and
refined over 2-3 decades by highly-paid and highly-experienced system
programmers, whereas the stuff you find in your average end-user
application was put together in an haphazard way in 1-4 years while
writing non-trivial parts of application code as well. Guess which
implementations will be leaner, meaner and less buggy...
CL was "big" and "slow", in a distant past, when you still could write
non-trivial applications without a real high-level language (e.g. in
C), and without an advanced substrate (e.g. only using libc and
POSIX), and still meet your dead-lines. In this case a CL
implementation would have to carry around unnecessary bagage, that the
C/POSIX implementation didn't need, and hence that one was smaller and
often faster as well. But that time is long gone (for at least a
decade in fact, though most programmers needed some time to cotton on
to the fact), and hence CL is small and fast, when compared to other
"solutions".
The only thing that I think CL has to do to keep up with the current
developments is to slowly but steadily incorporate "new" functionality
into the language, in the same professional manner as it did in the
past (i.e. not the Java-way of throwing everything in that comes
along). If we can keep up the migration of proven technology into the
language, then I think CL will still be around in another 40 years,
when proponents of Hyper-Kryton will be laughing at Avaj 2040 users...
Regs, Pierre.
PS: The short form of this diatribe is contained in various quotes,
like the following:
"Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp." -- Philip Greenspun
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Pierre R. Mai" wrote:
> The only thing that I think CL has to do to keep up with the current
> developments is to slowly but steadily incorporate "new" functionality
> into the language, in the same professional manner as it did in the
> past (i.e. not the Java-way of throwing everything in that comes
> along). If we can keep up the migration of proven technology into the
> language, then I think CL will still be around in another 40 years,
> when proponents of Hyper-Kryton will be laughing at Avaj 2040 users...
Ah, how lovely. I haven't really read this group since the september
that didn't end, and it's so nice to see a recent convert so passionate.
I am about to convert something written (reasonably well, I might add)
in Perl. We will convert it into LISP. That's right, kiddies, lisp. Why?
Well, if you've been following this thread much, you have already
figured out the reasons. Perl is a fine and upstanding language, as is
C, but they just don't have the same qualities as a language with a
decent expression of objects and the actions on them, and they certainly
don't allow for the all important ability to write and compile on the
fly.
It's the framework for a host and network based intrusion detection
system, and I simply cannot envision how it could be done other than in
lisp. No more adding signatures, and re-reading the database, nope. Nice
code that will allow us to change what an attack is based on stuff that
just happened, for instance. I'm really looking forward to it.
My only decisions are whether to purchase something that has CLIM, or
use something free that at least interfaces to whatever passes for
GINA/GLX these days. I might even try to write lisp/tk (now that sounds
like fun).
> "Any sufficiently complicated C or Fortran program contains an ad hoc
> informally-specified bug-ridden slow implementation of half of Common
> Lisp." -- Philip Greenspun
Even truer for C++ (shudder).
--
"Well, that's the squaw that stroked the camel's sack!"
--Kelly Bundy
Etaoin Shrdlu <······@deaddrop.org> writes:
> My only decisions are whether to purchase something that has CLIM, or
> use something free that at least interfaces to whatever passes for
> GINA/GLX these days. I might even try to write lisp/tk (now that sounds
> like fun).
Well, there's already with-wish. While Tcl/Tk is one of the most
frightening things I have ever worked with (wouldn't want anything
weird like _consistency_ in a language/toolkit, now would we), there
is much to be said for the fact that it just connects with a separate
program using plain text commands.
IMO there are already too many toolkits interfaced to the Lisp
interpreter with C, tying one to a particular Lisp implementation just
to use the toolkit. If at all possible, I think as much code as
possible should be done in pure Lisp.
For a project I was doing recently, I ended up basically writing my
own (pretty specialized) widget set on top of with-wish. It's got
some quirks (like you do have to know the wish options, but
inheritance and sensible defaults are built in to my stuff), and I've
only used it for one-time creation of widgets that then pass
information back to the main program, but it should be quite easy to
tweak for other uses (I've got several ideas right now).
It's at http://quadium.net/code/splash/ and if you'd like to use that
as a foundation for anything else, I'd be glad to work on it with
you. But you don't have to, of course.
--
vsync
http://quadium.net/ - last updated Fri Jun 16 00:38:12 MDT 2000
Orjner.
Etaoin Shrdlu wrote:
>and they certainly don't allow for the all important ability to write
>and compile on the fly.
You can do that with perl but it is not comparable to a real compiler.
First there's eval "" with dynamic class generators and such.
Second the bytecode compiler:
The bytecode is MUCH bigger than the sourcecode, so IO time beats the
parsing and optimizing advantage by far. And the compiler is not
optimizing too good.
I doubt if it will be able to improve on this at all, because of the
messy language. Type declarations would help.
Now they try to compress the bytecode on the fly but that's just hiding
the real problems behind.
--
Reini
Etaoin Shrdlu <······@deaddrop.org> writes:
> It's the framework for a host and network based intrusion detection
> system, and I simply cannot envision how it could be done other than in
> lisp. [...]
>
> My only decisions are whether to purchase something that has CLIM, or
> use something free that at least interfaces to whatever passes for
> GINA/GLX these days. I might even try to write lisp/tk (now that sounds
> like fun).
Now, my first two reactions are:
- of course lisp is a good language to write (most of) an IDS in, but:
- why on earth would one want CLIM, GINA or GLX for that?
I want my ideal IDS to:
- snoop approperiate segments of my network[1]
- detect known attacks, through the use of attack signatures
maintained by some external entity[2] that I *don't* need to trust
completely[3]
- detect *normal* behaviour, to the point of suggesting modifications
in the signature list to avoid false positives
- detect *abnormal* behaviour (and propose a signature), so that a
possible attack can be investigated *before* a signature is
available
- log via syslog and to (e.g. tcpdump-format) files
- tell me when something important happens[4]
Of these, only the last point could possibly use a gooey, but a gooey
will not be enough -- I may need to be paged.
[1] this is possibly best done in C, e.g. with libpcap
[2] i.e. I don't have the time to do this myself
[3] i.e. bad or malicious signatures should not be able to compromise
my network, let alone crash the IDS
[4] much the same way as a syslog scanner can do today
--
Arvid
* Arvid Gr�tting wrote:
> - why on earth would one want CLIM, GINA or GLX for that?
Because you want to sell some copies, and want some kind of GUI for it
so it's attractive to people? or if you use CLIm you might want the
cool commandline stuff you get with CLIM.
--tim
········@visi.com (David Thornley) writes:
> The common wisdom is that Lisp is big and slow. The interesting thing
> is that Lisp grew while becoming svelte. There seems to have been
> some reasons that Lisp had to be at least X big and Y slow, but
> now X and Y are small numbers relative to all the bloatware out there.
>
> To put it another way: Lisp was big and slow. It has grown and
> become somewhat faster, but it still tends to do low-level stuff slower
> than a good C/C++ implementation. Thing is, everything else has grown
> much faster, and how micro-efficient code is has become less and less
> important.
Another mechanism at work here is the growing complexity of all
programs, so that even "small" end-user applications are now quite
complex beasts. Since you need some advanced machinery to tame such
beasts, nearly all non-trivial applications now contain all of the
stuff that CL contains out of the box (things like GC, advanced
condition handling, large utility libraries, bignum arithmetic (=>
cryptograpy), advanced introspective OO systems, object serialization,
run-time patching and debugging aids, etc.), with the small difference
that the implementations in a CL system were designed, implemented and
refined over 2-3 decades by highly-paid and highly-experienced system
programmers, whereas the stuff you find in your average end-user
application was put together in an haphazard way in 1-4 years while
writing non-trivial parts of application code as well. Guess which
implementations will be leaner, meaner and less buggy...
CL was "big" and "slow", in a distant past, when you still could write
non-trivial applications without a real high-level language (e.g. in
C), and without an advanced substrate (e.g. only using libc and
POSIX), and still meet your dead-lines. In this case a CL
implementation would have to carry around unnecessary bagage, that the
C/POSIX implementation didn't need, and hence that one was smaller and
often faster as well. But that time is long gone (for at least a
decade in fact, though most programmers needed some time to cotton on
to the fact), and hence CL is small and fast, when compared to other
"solutions".
The only thing that I think CL has to do to keep up with the current
developments is to slowly but steadily incorporate "new" functionality
into the language, in the same professional manner as it did in the
past (i.e. not the Java-way of throwing everything in that comes
along). If we can keep up the migration of proven technology into the
language, then I think CL will still be around in another 40 years,
when proponents of Hyper-Kryton will be laughing at Avaj 2040 users...
Regs, Pierre.
PS: The short form of this diatribe is contained in various quotes,
like the following:
"Any sufficiently complicated C or Fortran program contains an ad hoc
informally-specified bug-ridden slow implementation of half of Common
Lisp." -- Philip Greenspun
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]