Joseph wrote:
> Is LISP a goodbeginner language?
>
For beginners I would recommend the variant "Scheme", and use
http://www.htdp.org/ as the place to begin. Of course, I would also
suggest that at some point you learn low-level programming, too (see my
sig).
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
Jonathan Bartlett wrote:
> Joseph wrote:
>
>> Is LISP a goodbeginner language?
>
> For beginners I would recommend the variant "Scheme", and use
> http://www.htdp.org/ as the place to begin.
But note that Scheme has a very different feel than Lisp, so if this
doesn't work for you, try an introduction to Common Lisp instead.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Joseph wrote:
> Is LISP a goodbeginner language?
Yes, see the page on educational resources at
http://lisp.tech.coop/Education
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
> Joseph wrote:
>
>> Is LISP a goodbeginner language?
>
>
> Yes, see the page on educational resources at
> http://lisp.tech.coop/Education
>
Is there something there about Lisp being specifically good as a first
language? Anyway, I agree with the "yes".
For one thing, someone could start with Logo, a language meant not just
to be learned as a first language but also to be learned by children. So
lots of resources aimed at beginning programmers can be found.
For another, the REPL and apropos and the decent error messages all make
learning easier.
Not torturing beginners with static typing is a big win.
The highly regular syntax also rocks. This is funny since the biggest
complaint about Lisp from the great programming unwashed is its syntax.
I wager beginners with their clean slates will not be so obtuse.
For older beginners, the new PCL book will let them hit the ground
running with meaningful examples.
But probably the best reason is that everyone will be using Lisp within
a few years, so a beginner starting with any other language has to
switch languages just when they are starting to get the hang of programming.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
> But probably the best reason is that everyone will be using Lisp
within
> a few years, so a beginner starting with any other language has to
> switch languages just when they are starting to get the hang of
programming.
Thats a great idea and I'd like to see it. But Lisp has been around
for over 40 years now and not taken off in this way. Why do you feel
it will happen now?
Mark
"Mark Tarver" <··········@ukonline.co.uk> writes:
> > But probably the best reason is that everyone will be using Lisp
> within
> > a few years, so a beginner starting with any other language has to
> > switch languages just when they are starting to get the hang of
> programming.
>
> Thats a great idea and I'd like to see it. But Lisp has been around
> for over 40 years now and not taken off in this way. Why do you feel
> it will happen now?
Mostly due to advances in hardware.
······@news.dtpq.com (Christopher C. Stacy) writes:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
>
>> > But probably the best reason is that everyone will be using Lisp
>> within
>> > a few years, so a beginner starting with any other language has to
>> > switch languages just when they are starting to get the hang of
>> programming.
>>
>> Thats a great idea and I'd like to see it. But Lisp has been around
>> for over 40 years now and not taken off in this way. Why do you feel
>> it will happen now?
>
> Mostly due to advances in hardware.
That's funny! Lisp ran from vacuum tube machines with punch cards, on
transistor machines, on VLSI machines, on massively parallel machines,
on Lisp machines, on CISC, on RISC, on workstations, on PC, with mice
and bitmaps, on space ships with robotic instruments, etc.
What kind of advances in hardware do you forsee that Lisp won't be
able to swallow as easily as it has done for 50 years?
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
Pascal Bourguignon wrote:
> That's funny! Lisp ran from vacuum tube machines with punch cards, on
> transistor machines, on VLSI machines, on massively parallel machines,
> on Lisp machines, on CISC, on RISC, on workstations, on PC, with mice
> and bitmaps, on space ships with robotic instruments, etc.
>
> What kind of advances in hardware do you forsee that Lisp won't be
> able to swallow as easily as it has done for 50 years?
I think it's ok to use CL for about everything now, since people
even accept all kinds of stuff running on Java, which tends to be
a lot slower.
The reasons for C and C++ for pretty much all application
programming until now used to be efficiency (ignoring Greenspun's
10th rule for a moment). Now that some amount of runtime
type-checking and garbage collection are more widely accepted,
Smalltalk and CL could gain ground, at least on the desktop and
server side. Embedded devices (and phones, PDAs) will likely
stick with C for a while (Java on them sucks).
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann wrote:
> Pascal Bourguignon wrote:
>
>> That's funny! Lisp ran from vacuum tube machines with punch cards, on
>> transistor machines, on VLSI machines, on massively parallel machines,
>> on Lisp machines, on CISC, on RISC, on workstations, on PC, with mice
>> and bitmaps, on space ships with robotic instruments, etc.
>>
>> What kind of advances in hardware do you forsee that Lisp won't be
>> able to swallow as easily as it has done for 50 years?
>
> I think it's ok to use CL for about everything now, since people even
> accept all kinds of stuff running on Java, which tends to be a lot slower.
I think that's incorrect. Java should generally be faster than Common
Lisp implementations. I haven't checked this, though, with concrete
benchmarks, but the JVM implementations by Sun and IBM contain some of
the most advanced dynamic compilation techniques. Other language
communities simply don't have the manpower to achieve the same degree of
sophistication.
The thing that appears to make Java slow is its Swing API which is
unnecessarily general - for example it allows changing look & feel at
runtime. Like Erich Gamma said, it's good to use patterns, but not all
of them. ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza wrote:
>> I think it's ok to use CL for about everything now, since people even
>> accept all kinds of stuff running on Java, which tends to be a lot
>> slower.
>
>
> I think that's incorrect. Java should generally be faster than Common
> Lisp implementations. I haven't checked this, though, with concrete
> benchmarks, but the JVM implementations by Sun and IBM contain some of
> the most advanced dynamic compilation techniques. Other language
> communities simply don't have the manpower to achieve the same degree of
> sophistication.
Maybe Java does better code optimization, but as you say, typical
Java code is bloated. A reason for this is that Design Patterns
aren't simply higher-order functions, or tiny macros, but rather
amount to writing huge amounts of code, only to make the code
reusable. And of course, that dynamism is slower than doing
something at macro time.
Java is just so unwieldy, that most code tends to blow up, since
it's hard to see the areas that could be abstracted.
> The thing that appears to make Java slow is its Swing API which is
> unnecessarily general - for example it allows changing look & feel at
> runtime. Like Erich Gamma said, it's good to use patterns, but not all
> of them. ;)
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann <···········@web.de> wrote:
>Java is just so unwieldy, that most code tends to blow up, since
>it's hard to see the areas that could be abstracted.
I remember recently seeing an inquiry on c.l.java about some solution
to parse a (relatively simply tree-structured) string and one of
the answers was to somehow convert it into xml and use a full-blown
xml parser to parse it. The straight-forward manual solution
would've been a couple (dozen) lines of code. No wonder then that
some Java programs are just terribly slow and fat. That's probably
a by-product of the language being used by many inexperienced
programmers who cannot approximate the cost of the libraries they're
using and who, instead of developing even simple algorithms themselves,
prefer to mechanically glue together existing libraries. And if
the interfaces don't fit, then use another fat library or three for
conversion.
mkb.
Matthias Buelow wrote:
> I remember recently seeing an inquiry on c.l.java about some solution
> to parse a (relatively simply tree-structured) string and one of
> the answers was to somehow convert it into xml and use a full-blown
> xml parser to parse it. The straight-forward manual solution
> would've been a couple (dozen) lines of code. No wonder then that
> some Java programs are just terribly slow and fat. That's probably
> a by-product of the language being used by many inexperienced
> programmers who cannot approximate the cost of the libraries they're
> using and who, instead of developing even simple algorithms themselves,
> prefer to mechanically glue together existing libraries. And if
> the interfaces don't fit, then use another fat library or three for
> conversion.
Programmers just don't pay attention in college anymore (if they
went there). Parsing looks like theory and nobody ever needs to
write a parser anyway (since there's compilers for everything
already, right?), so they don't bother to learn it.
Someone who can code a parser or even an interpreter or compiler
(no matter how simple) is a demi-god to them.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
On Tue, 26 Apr 2005 19:35:45 -0500, Ulrich Hobelmann
<···········@web.de> wrote:
>Parsing looks like theory and nobody ever needs to
>write a parser anyway (since there's compilers for everything
>already, right?), so they don't bother to learn it.
Thants not true. The antlr mailing list gets more traffic then the
ocaml mailing list and almost as much traffic as this newsgroup
( pretty good considering traffic on mailing lists is lower ).
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
Ulrich Hobelmann schrieb:
> Maybe Java does better code optimization, but as you say, typical
> Java code is bloated. A reason for this is that Design Patterns
> aren't simply higher-order functions, or tiny macros, but rather
> amount to writing huge amounts of code, only to make the code
> reusable. And of course, that dynamism is slower than doing
> something at macro time.
Hallo
Java needs to make small eficient parts. It is called "web-oriented".
This is not in any case a title for lisp.
A minimum of transported bytes is miles different from atomar design.
stefan
Pascal Costanza schrieb:
> Ulrich Hobelmann wrote:
>
>> Pascal Bourguignon wrote:
>>
>>> That's funny! Lisp ran from vacuum tube machines with punch cards, on
>>> transistor machines, on VLSI machines, on massively parallel machines,
>>> on Lisp machines, on CISC, on RISC, on workstations, on PC, with mice
>>> and bitmaps, on space ships with robotic instruments, etc.
>>>
>>> What kind of advances in hardware do you forsee that Lisp won't be
>>> able to swallow as easily as it has done for 50 years?
>>
>>
>> I think it's ok to use CL for about everything now, since people even
>> accept all kinds of stuff running on Java, which tends to be a lot
>> slower.
>
>
> I think that's incorrect. Java should generally be faster than Common
> Lisp implementations. I haven't checked this, though, with concrete
> benchmarks, but the JVM implementations by Sun and IBM contain some of
> the most advanced dynamic compilation techniques. Other language
> communities simply don't have the manpower to achieve the same degree of
> sophistication.
I think I can second that.
From some little tests I can say that Java does not so slow as one
would think. In several cases it was a good bit faster than natively
compiled lisp code.
The JIT compiler can sometimes do real magic. It analyses a situation at
runtime and can generate highly optimized code for a specific problem
(at runtime it has more information).
This is not a language issue. In principle this could be done with CL
too... it is just highly complicated.
Andr�
--
Andr� Thieme wrote:
> This is not a language issue. In principle this could be done with CL
> too... it is just highly complicated.
One could also use Armed Bear Common Lisp, which compiles to Jave byte codes.
Paul
On Wed, 27 Apr 2005 00:36:50 +0200, Pascal Costanza wrote:
>> I think it's ok to use CL for about everything now, since people even
>> accept all kinds of stuff running on Java, which tends to be a lot
>> slower.
>
> I think that's incorrect. Java should generally be faster than Common
> Lisp implementations.
Pascal, fortunately for Common Lisp your statement is nonsense.
> I haven't checked this, though, with concrete benchmarks, but the JVM
> implementations by Sun and IBM contain some of the most advanced dynamic
> compilation techniques.
Sure they do. This doesn't mean they can still better ahead of time
compilation into assembly language (where the ahead of time compilation
can also occur at run time).
> Other language communities simply don't have the manpower to achieve the
> same degree of sophistication.
Our language community doesn't need this same degree of sophistication. We
have COMPILE and a COMPILATION-SPEED setting available at run time for
those problems that are not amenable to pre-distribution compilation.
The Java Virtual Machine enforces horrific limitations that make talking
full advantage of a CPU's instruction set impossible. For example there is
no efficient way to detect integer overflow of a primitive, and this is
one of the reasons Common Lisps built upon Java are not optimally
efficient.
There is no 64-bit indexing of arrays. You show me Java code that can
index huge scientific data sets as fast as Lisp or C.
The JVM omits unsigned integers (apart from their use as 16-bit
characters).
The JVM has pathetic limitations upon how large a class can be. Code
generators sometimes have to break complicated methods up into separate
classes, with all the overhead that entails.
The JVM doesn't comply with the IEEE 754 floating point specification.[0]
Consider the overhead of trying to catch all floating point exceptions and
operate upon Invalid Operation, Overflow, Division-by-Zero, Underflow
and Inexact Result flags.
The Java Native Interface introduces extra overhead to interfacing with C,
more overhead than one would expect with a Lisp foreign function
interface.
Java the language has abysmal abstractions. A Java programmer is forced to
thrown away a lot of information necessary for superior just-in-time
compilation. The transformation to bytecode throws away even more
information. Are you aware that GCJ can't compile bytecode as well as it
can compile Java source?[1] Do you think any JIT compiler will be able to
reconstruct a single optimal method from one that had to be broken up to
get around class file limitations?
The Java community has put extraordinary resources into solving problems
their language priests created.
Regards,
Adam
[0] <http://www.jddarcy.org/Borneo/>
"How Java’s Floating-Point Hurts Everyone Everywhere"
<www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf>
[1] <http://gcc.gnu.org/java/faq.html#4_2>
Pascal Bourguignon <···@informatimago.com> writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > "Mark Tarver" <··········@ukonline.co.uk> writes:
> >
> >> > But probably the best reason is that everyone will be using Lisp
> >> within
> >> > a few years, so a beginner starting with any other language has to
> >> > switch languages just when they are starting to get the hang of
> >> programming.
> >>
> >> Thats a great idea and I'd like to see it. But Lisp has been around
> >> for over 40 years now and not taken off in this way. Why do you feel
> >> it will happen now?
> >
> > Mostly due to advances in hardware.
>
> That's funny! Lisp ran from vacuum tube machines with punch cards, on
> transistor machines, on VLSI machines, on massively parallel machines,
> on Lisp machines, on CISC, on RISC, on workstations, on PC, with mice
> and bitmaps, on space ships with robotic instruments, etc.
Most of those machines that you are referring to cost
between $15,000 and $10,000,000 (not including operating costs).
Of course, historically, Lisp did "take off", but only in the
context of relatively expensive computers. In the mid-1980s
Lisp was quite popular. A fact which is generally overlooked
by timelines published on the web is that the first workstation
that anyone was able to buy commercially was the Lisp Machine.
Lisp's brief popularity declined due to the price/performance
curve of workstations, the fact that it was an over-powered
language for the majority of applications that people wanted,
the underlying problem of a lack of education, etc.
> What kind of advances in hardware do you forsee that Lisp won't be
> able to swallow as easily as it has done for 50 years?
I don't know what you mean by "Lisp being able to swallow",
but obviously "most people" (the consumer market) could never
have afforded a $250,000 PDP-10, a $70,000 Lisp Machine, or
even a $15,000 workstation. Those were considered pricey even
by corporate standards. The more recent lesser-priced personal
computers, until a few years ago, were toys that were incapable
of running Lisp very effectively, or at all (and didn't have the
capacity to do very much, in any event).
Today we have computers with plenty of power to do things like
run Lisp at a cost around $300, and so Lisp is more accessible.
Therefore, more people can try Lisp, and I expect it to become
more popular than in the past, when most people couldn't run it.
Now that the hardware problem has been solved, I would revise the
OP's question about Lisp not becoming popular to a investigation of
the past 10 years or so, instead. Of course, that turns his flamebait
into a far less dramatic interrogative. And I think we mainly know
what the answer to the problem is: educational material, and the
availability of standard libraries. Both of which areas are continuing
to make pretty good progress, as far as I can tell. This is reflected
in the fact that Lisp _is_ in fact, becoming more popular.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Of course, historically, Lisp did "take off", but only in the
> context of relatively expensive computers. In the mid-1980s
> Lisp's brief popularity declined due to the price/performance
> curve of workstations, the fact that it was an over-powered
> language for the majority of applications that people wanted,
> the underlying problem of a lack of education, etc.
I forgot to add: "AI Winter", in which Lisp was the
demomized scapegoat for the oversold AI bubble crashing.
begin
See, I knew all those parens would lead to no good
end!
······@news.dtpq.com (Christopher C. Stacy) writes:
> Today we have computers with plenty of power to do things like
> run Lisp at a cost around $300, and so Lisp is more accessible.
> Therefore, more people can try Lisp, and I expect it to become
> more popular than in the past, when most people couldn't run it.
Those expensive computers of yesteryear were also what was needed
to deliver a Lisp application, not just to develop it.
Today's programmers have cheap computers that can be used
to develop programs in Lisp, but they can deliver the
resulting product to anybody's personal computer.
{Yeah, I should collect all my thoughts into one message before
hitting the SEND button...]
······@news.dtpq.com (Christopher C. Stacy) writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>> Today we have computers with plenty of power to do things like
>> run Lisp at a cost around $300, and so Lisp is more accessible.
>> Therefore, more people can try Lisp, and I expect it to become
>> more popular than in the past, when most people couldn't run it.
>
> Those expensive computers of yesteryear were also what was needed
> to deliver a Lisp application, not just to develop it.
They were the _only_ computers available.
> Today's programmers have cheap computers that can be used
> to develop programs in Lisp, but they can deliver the
> resulting product to anybody's personal computer.
Nowadays, in average, users have more powerful computers than programmers...
> {Yeah, I should collect all my thoughts into one message before
> hitting the SEND button...]
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
······@news.dtpq.com (Christopher C. Stacy) writes:
> {Yeah, I should collect all my thoughts into one message before
> hitting the SEND button...]
No problem, just define an :after message.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Christopher C. Stacy wrote:
> And I think we mainly know
> what the answer to the problem is: educational material, and the
> availability of standard libraries.
... and fragmentation. Common Lisp is not so common. In my admittedly
limited experience, I've discovered many libraries are dead, don't work
on the platform I'm interested in, or don't work on the Lisp
implementation that I have, or don't work as advertised.
Sorry, but it's true. Perhaps what Lisp needs a benevolent dictator.
Mark Carter wrote:
> Christopher C. Stacy wrote:
>
>> And I think we mainly know
>> what the answer to the problem is: educational material, and the
>> availability of standard libraries.
>
>
> ... and fragmentation. Common Lisp is not so common. In my admittedly
> limited experience, I've discovered many libraries are dead, don't work
> on the platform I'm interested in, or don't work on the Lisp
> implementation that I have, or don't work as advertised.
>
> Sorry, but it's true. Perhaps what Lisp needs a benevolent dictator.
Please no! What would he/she do? Any Lisp implementor can add
libraries and stuff to his/her implementation. That way (like in
the Scheme world, only that CL already has a useful base) there's
competition (= as many dictators as there want to be).
Most of the time it would be portable libraries anyway, that are
just ported to particular implementations (seems to work like
that, right now). An implementation that doesn't implement a
popular/good library, would probably be criticized by its users
(or they would do the porting).
So I really don't see what a dictator would buy you...
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Mark Carter <···········@yahoo.co.uk> writes:
> Christopher C. Stacy wrote:
> > And I think we mainly know
> > what the answer to the problem is: educational material, and the
> > availability of standard libraries.
>
> ... and fragmentation. Common Lisp is not so common. In my admittedly
> limited experience, I've discovered many libraries are dead, don't
> work on the platform I'm interested in, or don't work on the Lisp
> implementation that I have, or don't work as advertised.
>
> Sorry, but it's true. Perhaps what Lisp needs a benevolent dictator.
If you're saying something that is true, I don't know
why you would apologize. People here are donating
their time trying to help you solve your programming problem.
But this can only be done if you provide very specific
information. Your message does not contain any actual
information that might help solve your problem.
It is a statement of some vague dissatisfaction.
You raise several points.
On the subject of "dead" libraries, I don't see how this is different
from free contributed software in any other language. I see libraries
on SourceForge and whatever that appear to be abandoned (or worse,
entirely vaporware) in other languages all the time.
What particular Lisp library did you have a problem with?
Was it no longer available? Did it no longer work?
The same point is true for your "didn't work as advertised"
complaint. Which libraries in particular were you
dissatisfied with? How did the library vendor respond?
I wonder if perhaps you're just complaining about the of some
free software that you obtained, and somehow blaming Lisp?
How is this different from other languages?
There also seems to be some expectation that all Common Lisp
libraries would be portable. This is unreasonable because the
authors of those libraries could have used proprietary vendor
extensions to the language. But it's also somewhat reasonable,
since you'd think that in most cases there would be no need for
them to do so. It does have the word suggestive word "Common"
in it, after all, even if that's not what it was supposed to mean.
There are definitely a few pieces missing from ANSI Common Lisp:
streams, processes/threads, OS calls, FFI, and network IO.
But all of those things are addressed by least-common-denominator
standard libraries that are portable across all (or most, anyway)
implementations. The underlying functionality is mostly provided
by the vendors extensions, but you program to the portable API.
This area could still use some more improvement, but it's been
good enough for people to easily write libraries and programs
that run basically everywhere. For example, the CL-SQL database
library is very popular; it's built on the UFFI library.
So, please provide us with specific details about your problem.
Otherwise, I see no point at all in continuing this discussion.
Here's a suggestion for Lisp vendors and promoters:
One thing that Lisp doesn't really have is a great place
for one-stop shopping of portable standard libraries.
This leads people to perceptions like yours, when in fact I think
most libraries and most applications are entirely portable.
There are some good sites with nice collections, but the thing
that is missing is platform/library compatability library matrix
that would allow you to easily browse according to your requirements.
A would suggest an interface with a couple of scroll menus:
one for OS, and one for CL implementation. Maybe some other criteria
selectors would appear in some contexts (eg. database back-end).
This would be used with the library/application-type menu to
generate the search results page.
Mark Carter <···········@yahoo.co.uk> writes:
> Christopher C. Stacy wrote:
> > And I think we mainly know
> > what the answer to the problem is: educational material, and the
> > availability of standard libraries.
>
> ... and fragmentation. Common Lisp is not so common. In my admittedly
> limited experience, I've discovered many libraries are dead, don't
> work on the platform I'm interested in, or don't work on the Lisp
> implementation that I have, or don't work as advertised.
>
> Sorry, but it's true. Perhaps what Lisp needs a benevolent dictator.
If you're saying something that is true, I don't know
why you would apologize. People here are donating
their time trying to help you solve your programming problem.
But this can only be done if you provide very specific
information. Your message does not contain any actual
information that might help solve your problem.
It is a statement of some vague dissatisfaction.
You raise several points.
On the subject of "dead" libraries, I don't see how this is different
from free contributed software in any other language. I see libraries
on SourceForge and whatever that appear to be abandoned (or worse,
entirely vaporware) in other languages all the time.
What particular Lisp library did you have a problem with?
Was it no longer available? Did it no longer work?
The same point is true for your "didn't work as advertised"
complaint. Which libraries in particular were you
dissatisfied with? How did the library vendor respond?
I wonder if perhaps you're just complaining about the quality of
some free software that you obtained, and somehow blaming Lisp?
How is this different from other languages?
There also seems to be some expectation that all Common Lisp
libraries would be portable. This is unreasonable because the
authors of those libraries could have used proprietary vendor
extensions to the language. But it's also somewhat reasonable,
since you'd think that in most cases there would be no need for
them to do so. It does have the word suggestive word "Common"
in it, after all, even if that's not what it was supposed to mean.
There are definitely a few pieces missing from ANSI Common Lisp:
streams, processes/threads, OS calls, FFI, and network IO.
But all of those things are addressed by least-common-denominator
standard libraries that are portable across all (or most, anyway)
implementations. The underlying functionality is mostly provided
by the vendors extensions, but you program to the portable API.
This area could still use some more improvement, but it's been
good enough for people to easily write libraries and programs
that run basically everywhere. For example, the CL-SQL database
library is very popular; it's built on the UFFI library.
So, please provide us with specific details about your problem.
Otherwise, I see no point at all in continuing this discussion.
Here's a suggestion for Lisp vendors and promoters:
One thing that Lisp doesn't really have is a great place
for one-stop shopping of portable standard libraries.
This leads people to perceptions like yours, when in fact I think
most libraries and most applications are entirely portable.
There are some good sites with nice collections, but the thing
that is missing is platform/library compatability library matrix
that would allow you to easily browse according to your requirements.
A would suggest an interface with a couple of scroll menus:
one for OS, and one for CL implementation. Maybe some other criteria
selectors would appear in some contexts (eg. database back-end).
This would be used with the library/application-type menu to
generate the search results page.
Christopher C. Stacy wrote:
> Here's a suggestion for Lisp vendors and promoters:
>
> One thing that Lisp doesn't really have is a great place
> for one-stop shopping of portable standard libraries.
> This leads people to perceptions like yours, when in fact I think
> most libraries and most applications are entirely portable.
>
> There are some good sites with nice collections, but the thing
> that is missing is platform/library compatability library matrix
> that would allow you to easily browse according to your requirements.
> A would suggest an interface with a couple of scroll menus:
> one for OS, and one for CL implementation. Maybe some other criteria
> selectors would appear in some contexts (eg. database back-end).
> This would be used with the library/application-type menu to
> generate the search results page.
I think that's a very good idea, and could be combined with some kind of
CLRFI process. A commitment of three or more vendors to actively support
CLRFI standards would probably lead to some noticeable progress in that
area. A right balance that equally respects the needs of commercial and
open-source vendors would be required, though.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
······@news.dtpq.com (Christopher C. Stacy) writes:
> There also seems to be some expectation that all Common Lisp
> libraries would be portable. This is unreasonable because the
> authors of those libraries could have used proprietary vendor
> extensions to the language. But it's also somewhat reasonable,
Or the authors may not have access to, or interest in, platforms other
than the one(s) they currently use.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Mark Carter wrote:
> Christopher C. Stacy wrote:
>
>> And I think we mainly know
>> what the answer to the problem is: educational material, and the
>> availability of standard libraries.
>
> ... and fragmentation. Common Lisp is not so common. In my admittedly
> limited experience, I've discovered many libraries are dead, don't work
> on the platform I'm interested in, or don't work on the Lisp
> implementation that I have, or don't work as advertised.
In what sense is this different from any other language? The only
languages that don't have that problem are very young ones. Do you want
to switch language every five years?
> Sorry, but it's true. Perhaps what Lisp needs a benevolent dictator.
That's impossible because Lisp is essentially a design idea, not a
concrete language. No matter how hard someone would try to control a
Lisp dialect, you could easily deviate in any way you want. Unless you
start to add syntax, that is... ;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
······@news.dtpq.com (Christopher C. Stacy) writes:
> Today we have computers with plenty of power to do things like
> run Lisp at a cost around $300, and so Lisp is more accessible.
> Therefore, more people can try Lisp, and I expect it to become
> more popular than in the past, when most people couldn't run it.
Oh, I see. I understood the opposite.
Indeed, the advances in hardware help Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
Pascal Bourguignon wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>
>>"Mark Tarver" <··········@ukonline.co.uk> writes:
>>
>>
>>>>But probably the best reason is that everyone will be using Lisp
>>>
>>>within
>>>
>>>>a few years, so a beginner starting with any other language has to
>>>>switch languages just when they are starting to get the hang of
>>>
>>>programming.
>>>
>>>Thats a great idea and I'd like to see it. But Lisp has been around
>>>for over 40 years now and not taken off in this way. Why do you feel
>>>it will happen now?
>>
>>Mostly due to advances in hardware.
>
>
> That's funny! Lisp ran from vacuum tube machines with punch cards, on
> transistor machines, on VLSI machines, on massively parallel machines,
> on Lisp machines, on CISC, on RISC, on workstations, on PC, with mice
> and bitmaps, on space ships with robotic instruments, etc.
>
> What kind of advances in hardware do you forsee that Lisp won't be
> able to swallow as easily as it has done for 50 years?
Pascal, I think your disputation flag is stuck in the up position. You
might have to clear that manually. :)
IIANM, Mr. Stacy was pointing out that during Lisp's last ascendance one
needed serious hardware to run fast. Defense Dept kind of serious. More
serious than an Apple II with 32k RAM. Basic, Pascal, and then C took
over when microcomputers became an important place for apps to run.
Now we all have serious enough hardware and Lisp is growing /fast/.
Btw, that is another strong indicator for Lisp: it survived a twenty
year exile. meanwhile, all the marketing and installed base and
libraries in the world can't save Java.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> IIANM, Mr. Stacy was pointing out that during Lisp's last ascendance
> one needed serious hardware to run fast. Defense Dept kind of
> serious. More serious than an Apple II with 32k RAM. Basic, Pascal,
> and then C took over when microcomputers became an important place for
> apps to run.
I recently got form Amazon a dirty cheap (0.01$), used copy of "The
Rise of the Expert Company - How Visionary Companies are using
Artificial Intelligence to Achieve Higher Productivity and Profits" by
Feigenbaun et al., published in 1989.
The book describes this problem well. It talks about companies that
were genuinely interested in AI and related software (expert systems
tools written in Lisp are frequently mentioned). But the costs for
setting up even a small lab with a few Lisp Machines were often so
high, even for large corporations, that they were forced to use
smaller machines and more limited software.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"Mark Tarver" <··········@ukonline.co.uk> writes:
> But Lisp has been around
> for over 40 years now and not taken off in this way. Why do you feel
> it will happen now?
It is happening.
Every large program has a virtual lisp interpreter built into it.
It is just being kept secret.
vermicule wrote:
> "Mark Tarver" <··········@ukonline.co.uk> writes:
>
>
>> But Lisp has been around
>>for over 40 years now and not taken off in this way. Why do you feel
>>it will happen now?
>
>
> It is happening.
> Every large program has a virtual lisp interpreter built into it.
> It is just being kept secret.
Yes. OpenOffice hides Lisp in its C++/Java bridge, and Mozilla
camouflages it as XML + JavaScript.
Don't know about NextStep/Cocoa, KDE, and Gnome, but they probably
have it somewhere, too.
The Sawfish Gnome window manager (which used some Lisp dialect)
was replaced by Metacity, which probably implements the Lisp in C,
so again, it's more secret ;)
Greenspun's 10th rule rules.
--
No man is good enough to govern another man without that other's
consent. -- Abraham Lincoln
Ulrich Hobelmann <···········@web.de> writes:
> vermicule wrote:
> [...]
>> Every large program has a virtual lisp interpreter built into it.
>> It is just being kept secret.
>
> Yes. OpenOffice hides Lisp in its C++/Java bridge, and Mozilla
> camouflages it as XML + JavaScript.
>
> Don't know about NextStep/Cocoa, KDE, and Gnome, but they probably
> have it somewhere, too.
Yes, how do you think they implemented Xcode, allowing the developper
to modify methods and variables in a running Objective-C process?
> [...]
> Greenspun's 10th rule rules.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
"Kenny Tilton" <·······@nyc.rr.com> schrieb im Newsbeitrag
····························@twister.nyc.rr.com...
...
> But probably the best reason is that everyone will be using Lisp within
> a few years, ...
Ooops - really great news! Are you sure?
:)
Andreas
Andreas Thiele wrote:
> "Kenny Tilton" <·······@nyc.rr.com> schrieb im Newsbeitrag
> ····························@twister.nyc.rr.com...
> ...
>
>>But probably the best reason is that everyone will be using Lisp within
>>a few years, ...
>
>
> Ooops - really great news! Are you sure?
Andreas and Mark,
I was out on a limb saying that two years ago, but now, if you think
about it... game over:
Python is the Lisp of C
Groovy is the Lisp of Java, the Lisp of C++
Ruby is the Lisp of Smalltalk
None of the above can match Lisp
TDD has buried static typing
c.l.l. is awash with newby rug rats
The trend is clear: dynamic languages are dragging down statics from
behind, and Common Lisp is the uncontested champ and will stay that way
since Lisp can morph effortlessly to pick up new ideas (such as OOP or
constraints or logic programming). The refugees have not departed C++
and static Java only to stop at Python or Groovy, when Common Lisp is
growing every day with more and more library support.
Finally, the best programmers prefer Common Lisp by a mile, hands down.
That alone tells us where the field is going.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> I was out on a limb saying that two years ago, but now, if you think
> about it... game over:
>
> TDD has buried static typing
Interestingly, an embedded Lisp language recently claims to have "the
most powerful type system of any existing functional language,
including ML and Haskell."
http://www.lambdassociates.org/
"Do I contradict myself? Very well, then, I contradict myself. I am
large, I contain multitudes." -- Walt Whitman, speaking for Common Lisp.
Kenny Tilton <·······@nyc.rr.com> writes:
> Finally, the best programmers prefer Common Lisp by a mile, hands
> down. That alone tells us where the field is going.
I'll just say that either you are a prophet or you are crazy.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
David Steuber <·····@david-steuber.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Finally, the best programmers prefer Common Lisp by a mile, hands
> > down. That alone tells us where the field is going.
>
> I'll just say that either you are a prophet or you are crazy.
I dislike this puritanical view of things. Why can't Lisp's
prognosticators just be drunk? Intoxicated by the language.
Sometimes that means drunken inspiration, sometimes drunken rambling,
but right or wrong, they've found where they want to be
thankyouverymuch.
That said, have you looked at the European Lisp meetings' growth curve?!?!
(hikkup)
David Steuber <·····@david-steuber.com> wrote:
+---------------
| Kenny Tilton <·······@nyc.rr.com> writes:
| > Finally, the best programmers prefer Common Lisp by a mile, hands
| > down. That alone tells us where the field is going.
|
| I'll just say that either you are a prophet or you are crazy.
+---------------
What, he can't be both?!?! ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
David Steuber <·····@david-steuber.com> writes:
> I'll just say that either you are a prophet or you are crazy.
Kenny would make a great Old Testament type prophet.
David Steuber wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Finally, the best programmers prefer Common Lisp by a mile, hands
>>down. That alone tells us where the field is going.
>
>
> I'll just say that either you are a prophet or you are crazy.
>
What part of my sig do you not understand?
kenny
--
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Python is the Lisp of C
> Groovy is the Lisp of Java, the Lisp of C++
> Ruby is the Lisp of Smalltalk
I was under the impression that Ruby was the Dylan of Smalltalk.
AFAIK, it's not any more dynamic than ST, but it does have more
syntax.
Thomas F. Burdick wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>> Python is the Lisp of C
>> Groovy is the Lisp of Java, the Lisp of C++
>> Ruby is the Lisp of Smalltalk
>
>
> I was under the impression that Ruby was the Dylan of Smalltalk.
> AFAIK, it's not any more dynamic than ST, but it does have more
> syntax.
Thx, I was winging it on Ruby. :)
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
"Joseph" <·············@gmail.com> writes:
> Is LISP a goodbeginner language?
I wish it was my first programming language. I would be a true wizard
by now.
My opinion is that Common Lisp is suitable as a first language that
you end up using for the rest of your life.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum