What's so great about lisp?
Kris Cipa
I had to use lisp in college for a course, and it looked like a
horribly primitive and useless contraption. We even had to use emacs to
use it, in the 21 century!. I have avoided it ever since. However I
find more and more people rhapsodizing about how cool Lisp is and what
an advanced language it supposedly is. I just don't get it: I mean do
those people claim that we have made no progress in all the years since
the early days of computing when lisp was used?
I'd like to know, what's the secret?
Regards
--
Kris.
Pascal Costanza
> What's so great about lisp?
See http://wiki.alu.org:80/Success_Stories and
http://wiki.alu.org:80/Evaluate_Lisp
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Tonguc Yumruk
Well, I'm not an expert on the history of programming languages, but
as far as I can see most of the "new and cool" features of current
programming languages existed on the Lisp arena for a really long
time. So I think the answer is yes, we didn't made too much
progress. Of course this is just an idea of a Lisp newbie...
To how intresting Lisp can be, I recommend you to start by watching
Rainer Joswig's Lisp Machine videos [1]. Then, you can read Pascal
Costanza's Hİghly Opinionated Guide to Lisp [2]. I think these will
show you some of the secrets about Lisp.
[1] http://lispm.dyndns.org/
[2] http://p-cos.net/lisp/guide.html
PS: Emacs is not a requirement for Lisp programming, but it makes life
a lot easier. Take a look at SLIME
(http://common-lisp.net/project/slime/).
--
Love Respect GNU/Linux
########################################################################
BOFH excuse #431:
Borg implants are failing
########################################################################
Tonguç Yumruk
Stefan Scholl
> What's so great about lisp?
After all those years it still attracts programming language trolls.
Ulrich Hobelmann
> I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
Well, the majority doesn't use FORTRAN anymore, but moved on to C
dialects (like Java). The minority moved on from LISP 1.5 to Common
Lisp, Scheme, ML, Haskell and other more modern languages.
The mainstream made lots of progress, in gradually picking up Lisp
features (dynamic memory, garbage collection, dynamic typing). They
emulate macros by using XML and code generating programs on it.
> I'd like to know, what's the secret?
If you are really interested, read Practical Common Lisp and On Lisp,
otherwise just ignore the Lisp world. Your choice...
--
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)
Panu Kalliokoski
bit won't hurt :)
In <1127472026....@z14g2000cwz.googlegroups.com> "Kris Cipa" <kristi...@yahoo.co.nz> writes:
>What's so great about lisp?
Many things. Which, depends on which lisp language (or implementation)
you are talking about.
A few that come to my mind include:
* symbols
* lists
* write representations (s-expressions)
* homoiconicity
* first-class functions
* closures
* recursion
* debugging
* REPL
* dynamic typing
* side-effectlessness
* good macros
* smart compilers
(... of course, the list could go on forever...)
>I mean do those people claim that we have made no progress in all the
>years since the early days of computing when lisp was used?
This question is too imprecise: first, "those people" certainly does not
include _all_ Lisp aficionados; second, Lisp has not ceased to be used,
so it's hard to say which time "when lisp was used" refers to; third, as
there has been much progress in Lisp since its birth, so the claim
wouldn't hold even if the other languages had not progressed at all;
fourth, since Lisp's influence on other languages is so vast (for
example, the birth of procedural programming is in part due to Lisp and
the birth of OOP is definitely affected by Lisp) it's not possible to
separate the progress of other programming languages from the progress
of Lisp.
But still, if you would ask whether _I_ claim that programming
environments and languages (not "we") have made no progress since the
days when Lisp machines were still actively developed, I would say,
"yes". Which, of course, doesn't mean there hasn't been a lot of
progress in communication media, everyday usage of cryptography,
licensing, and availability of cheap hardware.
Panu
--
personal contact: ate...@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kal...@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
Cor Gest
"Kris Cipa" <kristi...@yahoo.co.nz> writes:
> What's so great about lisp?
Nothing at all,
It is just like human proliferation:
Any person can do it.
But for all its greatness to be enjoyed, one must be smart enough to learn.
Cor
--
To really make a mess of things one should use a computer
Kristof Bastiaensen
Panu Kalliokoski wrote:
> <snip>
>
> >I mean do those people claim that we have made no progress in all the
> >years since the early days of computing when lisp was used?
>
> This question is too imprecise: first, "those people" certainly does not
> include _all_ Lisp aficionados; second, Lisp has not ceased to be used,
> so it's hard to say which time "when lisp was used" refers to; third, as
> there has been much progress in Lisp since its birth, so the claim
> wouldn't hold even if the other languages had not progressed at all;
> fourth, since Lisp's influence on other languages is so vast (for
> example, the birth of procedural programming is in part due to Lisp and
> the birth of OOP is definitely affected by Lisp) it's not possible to
> separate the progress of other programming languages from the progress
> of Lisp.
>
While I mostly agree with this paragraph, isn't the birth of OOP more
attributable to smalltalk? Early smalltalk systems had some features
of lisp (such as garbage collection), but the OOP system was quite a
different paradigm from lisp. Lisps only later caught on with OOP.
IMHO support for OOP is one of the weak spots in scheme and lisp.
Kristof Bastiaensen
Panu Kalliokoski
>> example, the birth of procedural programming is in part due to Lisp and
>> the birth of OOP is definitely affected by Lisp) it's not possible to
>While I mostly agree with this paragraph, isn't the birth of OOP more
>attributable to smalltalk? Early smalltalk systems had some features
>of lisp (such as garbage collection), but the OOP system was quite a
>different paradigm from lisp. Lisps only later caught on with OOP.
>IMHO support for OOP is one of the weak spots in scheme and lisp.
Well, depends on your definition of "attributable". As Alan Kay says,
some parts of Smalltalk's designs are attributable to Lisp; and the
theoretical foundations of OOP lie in "frame networks", which were
invented to model concepts in symbolic AI programs, developed on, you
guessed it, Lisp systems.
Now, about the following I'm not sure: I think the reason why language
support for OOP in Lisp was introduced so late is that it was too easy
to implement _within_ the language. You can write a very advanced,
delegation-based object system with multiple inheritance in a hundred
lines of Scheme; everybody just made up their _own_ object systems if
they wanted one and it took a _long_ time to standardise an object
system that would not irritate anybody.
That said, Lisp machines had OO facilities (such as flavors) at the same
time that Smalltalk machines had OO facilities, so I don't think the
statement "only later caught on" holds.
Ben
> those people claim that we have made no progress
> in all the years since
> the early days of computing when lisp was used?
It's funny I read this today. Yesterday I picked up a system
engineering book from 1977. You know what I found in it? The problems
they had 30 years ago are the *EXACT* same problems we face today.
Nothing has changed. Nothing has improved. As smart as we like to
think we are, the software development industry is going in circles.
I think the return to lispishness by so many languages is showing
that we know how to write software. We've always known. The problems
we have getting predictable, quality software on a large scale don't
originate at the keyboard. That tells me that new languages aren't
going to help.
I have a lot of ideas about what will help, but I'm sure this the
wrong place for THAT rant. :)
-Ben
Pascal Costanza
To a certain extent, you could argue that Lisp 1.5 already had
object-oriented features, by providing identity and property lists.
(It's a stretch, I know. ;)
The contribution of Smalltalk was indeed to identify the paradigm, give
it a name, and distill it to a minimal set features. This is not unlike
Scheme that successfully distilled the notion of lexical scoping to a
minimal set of features.
> IMHO support for OOP is one of the weak spots in scheme and lisp.
This is a non-sequitur. There is CLOS integrated into Common Lisp, and
there is Tiny CLOS and its derivatives, plus a bunch of other object
systems for Scheme. Indeed, it's relatively straightforward to implement
a simple object-oriented extension in a few lines of Scheme or Lisp code.
Alan Kay has acknowledged that the CLOS Metaobject Protocol is an
important contribution, and I think that Lisp and Scheme are still ahead
of other languages in that regard, including Smalltalk. (However, Brian
Foote has implemented a CLOS-style metaobject protocol for Smalltalk
that he talked about at this year's ECOOP.)
Duane Rettig
> What's so great about lisp?
Many people have already given you answers to this question and
to the succeeding paragraph. However, they are given from the
point of view of people who have bought into Lisp, and who already
know the answer. Now, I don't know about the Scheme community,
but it's probably safe to say that in the Common Lisp community
most of the adherents come to Common Lisp not as a first language.
So they have at one point in time asked precisely the same question
you are asking here. For an interesting set of insights into what
these people were thinking when they came to learn Lisp, take a
browse through:
http://wiki.alu.org/The_Road_To_Lisp_Survey
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Drew Mills
in 1985. Since then I've moved to a bunch of other languages. I've
learned C, C++, Java, VB, Perl, Ruby, and on and on over the past 20
years. And I can tell you that the most fun I've had is when I can
squeeze in some Lisp programming over the last two decades.
I've not done exhaustive comparisons to say why its better. But I
know that I code faster, I debug faster, I think faster in Lisp. And I
can't really say that my experience is that deep with Lisp. But it
sure is a heck of a lot of fun.
Drew
ana...@earthlink.net
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
As Tonto said, "what do you mean 'we'"? Some folks are making
progress. Yes, they could have just made the leap in, say, 1980, but
they are moving. In their defense, technology changes have made the
"lisp overhead" less of an issue. (It wasn't as much an issue as they
claimed even then, but ....)
Ron Garret
"Kris Cipa" <kristi...@yahoo.co.nz> wrote:
> What's so great about lisp?
Macros.
Actually, that's not the real answer. What's great about Lisp is that
its surface syntax is the same for its code and one of its data
structures. That enables the easy implementation of myriad cool
features that are difficult or impossible [1] in other languages. This
includes macros, but also things that most people using other languages
wouldn't even begin to dream of, e.g.
http://www.cs.utexas.edu/users/moore/acl2/
Common Lisp also has a pretty cool object model based on generic
functions rather than message passing that no other language has.
(The list of features unique to Lisp used to be much longer, but other
languages have slowly been catching up.)
Finally, Lisp is great because at its core it is a very simple language.
Lisp is in fact simultaneously the simplest and the most powerful [2]
programming language ever invented (some would say "discovered"). Once
you come to realize this all other languages start to feel like a waste
of time.
rg
[1] "Impossible" in the sense of being unable to create a reasonable
user interface within the language, not in the sense of being
uncomputable.
[2] "Most powerful" in the sense that there are features that Lisp has
that no other language has, and at the same time there are no features
that any other language has that Lisp does not have (or could not be
easily implemented within the language).
Paolo Amoroso
"Kris Cipa" <kristi...@yahoo.co.nz> writes:
> What's so great about lisp?
You tell me:
Practical Common Lisp
http://www.gigamonkeys.com/book/
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
drewc
What's so great about jazz?
I had to listen to jazz in college for a course, and it sounded like a
horribly primitive and toneless composition. We even had to use records
to hear it, in the 21 century!. I have avoided it ever since. However I
find more and more people rhapsodizing about how cool Jazz is and what
an advanced genre it supposedly is. I just don't get it: I mean do
those people claim that we have made no progress in all the years since
the early days of recording when jazz was used?
I'd like to know, what's the secret?
"Man, If you have to ask what jazz is you'll never know"
-- Louis Armstrong
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
Matthias
drewc
> drewc <dr...@rift.com> writes (with-tongue-planted-firmly-in-cheek):
>
>>What's so great about jazz?
>>I had to listen to jazz in college for a course, and it sounded like a
>>horribly primitive and toneless composition. We even had to use records
>>to hear it, in the 21 century!
>
>
> listening to jazz music I heard on the streets, which was
> played by musicians live (within a pub) and with no electrical
> amplification.
>
> Even from the very distance one could here immediatly that
> this was not recorded music. So you should go to places where
> jazz music is played live -- not listen to records.
>
> When I heard that music I thought, "What a lie, to suggest
> that music can be recorded on technical media!"
Did I forget a smiley somewhere? While i agree that Jazz is best
experienced live, i wanted to show the correlation between Jazz and the
early recording industry, and relate that to LISP and the early
computing industry.
Also, vinyl albums (records) and emacs are both very old technology for
which a suitable replacement has yet to be found. Music sounds better on
Wax, text edits better in Emacs.
>>I have avoided it ever since. However I find more and more
>>people rhapsodizing about how cool Jazz is and what an advanced
>>genre it supposedly is. I just don't get it: I mean do those
>>people claim that we have made no progress in all the years
>>since the early days of recording when jazz was used? I'd like
>>to know, what's the secret?
>
>
> The type of music people are praising and prefer is usually
> not determined by intrinsic qualities of the music but by
> certain social conventions. As a member of a certain
> subculture one usually does have to adhere to a certain
> musical culture. This correlation was observed by
> sociologists.
The programming language people are praising and prefer is usually
not determined by intrinsic qualities of the language but by
certain social conventions. As a member of a certain
subculture one usually does have to adhere to a certain
linguistic culture. This correlation was observed by
sociologists.
Pascal Bourguignon
> What's so great about lisp?
It's a meta-programming language.
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
Yes, indeed, we've made no progress.
> I'd like to know, what's the secret?
The secret as Paul Grahams puts it, is that lisp is not a programming
language, it's a mathematical theorem. Pythagore's theorem is still
valid 2600 years later and still will be valid for ever.
http://paulgraham.com/icad.html
--
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
Pascal Bourguignon
> I have a lot of ideas about what will help, but I'm sure this the
> wrong place for THAT rant. :)
There are a couple of newsgroups that could be right on topic for this
rant, but AFAIK they're less read than c.l.l, so I'd be glad if you shared.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
Panu Kalliokoski
>[2] "Most powerful" in the sense that there are features that Lisp has
>that no other language has, and at the same time there are no features
>that any other language has that Lisp does not have (or could not be
>easily implemented within the language).
Well, depends on what you mean by "easily implemented", but things that
could be easier to implement IMO include lazy evaluation, backtracking
execution (although Scheme's call/cc makes it pretty easy), and
reversible execution (would require support in primitives).
Lazy evaluation and backtracking can be universally achieved by
implementing one's own version of |eval| or code-walking macros, but I
don't consider things like that very easy. Of course, a greatly
simplified version is probably OK, but taking into account the
evaluation of all user-defined data types and control structures can be
messy...
And reversible execution, such as "'(a b c) == (append ?x '(c)), deduce
?x" requires support on primitive level. So if you're going to
implement that, you'll need to redefine all primitives.
I do agree that these are even harder to implement in many other
languages.
Geoffrey Summerhayes
"Kris Cipa" <kristi...@yahoo.co.nz> wrote in message
news:1127472026....@z14g2000cwz.googlegroups.com...
For me, freedom.
Most languages force you to tackle a problem on the language's terms.
Java implies objects, for example. The more you use the language, the
more you tackle problems from it's perspective, but every once and a
while don't you catch yourself thinking, "If I was programming in
language X, I'd just write like this and be done, instead of having to
come up with a way to crowbar it into language Y."
Lisp's big strength is it's ability to adapt to the solution. If you've
come up with an elegant algorithm, you don't have to hammer it to fit
the language. Lisp handles most paradigms already, but if it still doesn't
fit, then you hammer the language to fit the solution.
--
Geoff
Thomas F. Burdick
> Kris Cipa wrote:
> > What's so great about lisp?
> > I had to use lisp in college for a course, and it looked like a
> > horribly primitive and useless contraption. We even had to use emacs to
> > use it, in the 21 century!. I have avoided it ever since. However I
> > find more and more people rhapsodizing about how cool Lisp is and what
> > an advanced language it supposedly is. I just don't get it: I mean do
> > those people claim that we have made no progress in all the years since
> > the early days of computing when lisp was used?
> > I'd like to know, what's the secret?
> > Regards
> > --
> > Kris.
>
> What's so great about jazz?
> I had to listen to jazz in college for a course, and it sounded like a
> horribly primitive and toneless composition. We even had to use records
> to hear it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Jazz is and what
> an advanced genre it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of recording when jazz was used?
> I'd like to know, what's the secret?
Damn, Drew wins!
> "Man, If you have to ask what jazz is you'll never know"
> -- Louis Armstrong
And I never thought I'd see this quote used in relation to a
programming language. Much less used well.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Jock Cooper
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
> Regards
> --
> Kris
You will never get what is so great about lisp until you have
programmed in and wrestled with other languages for awhile. Go off
and use VB/C/C++ and what not. If you are fed up with programming in
10 years then come and look at Common Lisp again.
We can spew off a list of features all day but in my experience the
response to that is generally along the lines of 'why would I need to
do that?' or 'I can do something similar by doing [some pain in the ass
pseudo substitute]'. eg I don't a macro when I can just cut and
paste code.
Tayssir John Gabbour
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
As far as I can tell, people used to teach Lisp badly. You know, boring
lists and functions. Not much focus on macros, LOOP and arrays o' doom.
Or maybe it was more word-of-mouth or something, and it was best to
actually work with Lispers.
But now we have things like http://www.gigamonkeys.com/book/ and wikis.
Tayssir
Frank Buss
> In article <1127472026....@z14g2000cwz.googlegroups.com>,
> "Kris Cipa" <kristi...@yahoo.co.nz> wrote:
>
>> What's so great about lisp?
>
> Macros.
ack. Currently I'm writing a Plugin on MacOS and sometimes I'm feeling like
a macro preprocessor. See for example this nice definition:
http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/public/npupp.h
There are 24 lines of code to define one function for the Plugin interface.
Ok, this is the header, only, and I don't have to write it myself, but to
use it, I have to write the functions and in another place I have to fill a
struct with these function pointers with some helper function, one line for
each function. In Lisp you would just define a special define-netscape-func
as a macro and the rest, including the 24 lines per function, will be
generated automaticly.
So why I don't use Lisp for implementing it, if it is so great? If you give
me a FFI, which works with all the tricks for UPP functions, dynamic Plugin
loading on different architectures and the like, I'll do it, but I fear
that I have to write much of the low-level stuff by myself, so I'm faster
being a preprocessor.
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
ray...@gmail.com
'secret' of Lisp is to program something non-trivial in it. You won't
be able to appreciate it until you do.
Matthias Buelow
>[2] "Most powerful" in the sense that there are features that Lisp has
>that no other language has, and at the same time there are no features
>that any other language has that Lisp does not have (or could not be
>easily implemented within the language).
How do you ("easily") implement a polymorphic type system for Common
Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
well-known Lisp, such as Scheme) so that you can make any Common
Lisp (or Scheme, ...) program be statically type checked?
There are indeed many things that can be (more or less straightforward)
implemented in, or emulated with (Common) Lisp but your claim that
there are _no_ features of any other language that cannot be "easily"
(I'd say, "naturally") expressed in Lisp is a bit strong.
mkb.
Ray Dillinger
> "Ben" <benb...@gmail.com> writes:
>
>> I have a lot of ideas about what will help, but I'm sure this the
>>wrong place for THAT rant. :)
>
>
> There are a couple of newsgroups that could be right on topic for this
> rant, but AFAIK they're less read than c.l.l, so I'd be glad if you shared.
>
Agreed, but if you do go ahead with it, please use a different subject
line; I don't want to have something potentially cool mixed into yet
another "why use lisp" iteration.
Bear
justinhj
introductory AI programming course, where lisp was the topic for a
couple of weeks. In that short time all we learned was about lambda
expressions and their relation to lisp. After that we did some things
with lists and that was it. The rest of undergraduate level AI was done
in Prolog.
>From that kind of introduction by someone who doesn't really know lisp,
you're not going to develop much enthusiasm, and I didn't.
Luckily as has been said, the internet and recent books now provide a
pleasant and rapid entry into the world of lisp for those willing to
invest the time.
Part of the problem seems to be the introduction of lisp as a language
purely for AI research, when in fact I learned that it is very much a
general purpose language. Secondly any introduction that focuses on
lisp as a list processor that doesn't seem to have other data
structures like arrays, strings etc, when in fact it does have all
those things, leaves the student with a poor impression.
Ray Dillinger
> Stefan Ram wrote:
>
>> Even from the very distance one could here immediatly that
>> this was not recorded music. So you should go to places where
>> jazz music is played live -- not listen to records.
>>
>> When I heard that music I thought, "What a lie, to suggest
>> that music can be recorded on technical media!"
Ah yes; "is it live or is it <elided>?" was a cruel joke.
You might not be able to tell with an amplified performance,
but on live performance with unamplified voice or acoustical
instruments there was never really any comparison.
Honestly, I think it's more about storage and reproduction issues
than a recording issue. CD's use something like ten megabytes a
minute to store a raw sound format; that's really only about a
twentieth of what you need, I think.
Unfortunately, it's "enough" to drive conventional mikes and
speakers to the limits of their respective performance envelopes.
To really take advantage of higher resolution recordings, you
have to go to technologically advanced substitutes such as
helium-ion speakers.
But that's not the way music seems to be going. Instead, we're
getting MP3's, which have smaller bandwidth but utterly mangle
any subtle sounds.
Bear
Christopher C. Stacy
> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
>
> >[2] "Most powerful" in the sense that there are features that Lisp has
> >that no other language has, and at the same time there are no features
> >that any other language has that Lisp does not have (or could not be
> >easily implemented within the language).
>
> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?
You can't make it so, for "any" program -- your are proposing a
tautology, because you can't statically type check all classes of
computer programs. But it would be easy to implement, in Lisp,
a suitable language for embedding with Common Lisp.
Ron Garret
Matthias Buelow <m...@incubus.de> wrote:
> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
>
> >[2] "Most powerful" in the sense that there are features that Lisp has
> >that no other language has, and at the same time there are no features
> >that any other language has that Lisp does not have (or could not be
> >easily implemented within the language).
>
> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?
By shadowing defun.
> There are indeed many things that can be (more or less straightforward)
> implemented in, or emulated with (Common) Lisp but your claim that
> there are _no_ features of any other language that cannot be "easily"
> (I'd say, "naturally") expressed in Lisp is a bit strong.
Well, it all hinges, of course, on the meaning of the word "easily".
But ACL2 provides static type checking (and much, much more) embedded
within CL, so we need not speculate in this case. The incremental cost
of adding such a system to CL is now zero.
rg
Lars Rune Nøstdal
> What's so great about lisp?
> I had to use lisp in college for a course, and it looked like a
> horribly primitive and useless contraption. We even had to use emacs to
> use it, in the 21 century!. I have avoided it ever since. However I
> find more and more people rhapsodizing about how cool Lisp is and what
> an advanced language it supposedly is. I just don't get it: I mean do
> those people claim that we have made no progress in all the years since
> the early days of computing when lisp was used?
> I'd like to know, what's the secret?
> Regards
I really dunno. Do you?
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
Ben
>
> There are a couple of newsgroups that could be right on
> topic for this
> rant, but AFAIK they're less read than c.l.l, so I'd be
> glad if you shared.
Well, I never pass up an invitation to grump and holler. Regardless
of language, platform or goal, when projects hit three or four million
lines of code, cancellation rates skyrocket. When we read "Mythical
Man Month", "Peopleware", "Agile Software Development", or just about
any book about software processes and management, we find a common
theme: Software development is hard. It requires adaptive processes,
_skilled_engineers_, and a LOT of communication to make sure that
knowledge and experience are passed between workers.
There is no surprise in that. If you ever read the Wall Street
Journal, you'll find that one of their favorite topics is the need to
pay top dollar for skilled, experienced executives to direct a company.
Software engineering is no different - experience and skill counts and
can mean the difference between success and failure. It is important
to hire developers who understand how to get work done, and get work
done correctly.
The corporations with the dollars to invest in large software
programs have categorically rejected this idea. I don't think that
anyone doubts the truth, but companies are not interested in that
answer. They would rather fail than do what is necessary for success -
pay for talented developers. Every company I have worked for, or have
seen friends work for, has adopted a "new college hire only" policy for
years at a time. They clamp down on raises, people quit, and all the
active projects are crippled. Schedules slip for YEARS. After a
while, the restriction is reduced, and a few experienced people come
in. Some of the college hires have figured stuff out by then, and
progress resumes. A project or two is successful, then the whole thing
starts again.
The difference between successful large projects and failures is the
people. Experts in the field have been saying that for 25-30 years.
Instead of listening, the industry has banged its head on the wall of
failure. Sure, a dent has been made. I think the success rate has
risen from 5% to about 15%. Yay! 50 more years, and we'll be half-way
there!
You may now return to Lisp. :)
Matthias Blume
> In article <3pjj9bF...@news.dfncis.de>,
> Matthias Buelow <m...@incubus.de> wrote:
>
>> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
>>
>> >[2] "Most powerful" in the sense that there are features that Lisp has
>> >that no other language has, and at the same time there are no features
>> >that any other language has that Lisp does not have (or could not be
>> >easily implemented within the language).
>>
>> How do you ("easily") implement a polymorphic type system for Common
>> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>> well-known Lisp, such as Scheme) so that you can make any Common
>> Lisp (or Scheme, ...) program be statically type checked?
>
> By shadowing defun.
It is not that easy. Hindley-Milner (as well as many other things)
depend on certain properties of the language -- in particular that
there are some things that one canNOT do.
There is no language where "everything is expressible" because
sometimes one would like to express that some other thing is not
expressible. (That's similar to the old question whether God -- who
"can do anything" -- could create a stone so heavy that He cannot lift
it...)
(another) Matthias
Ray Dillinger
> In article <3pjj9bF...@news.dfncis.de>,
> Matthias Buelow <m...@incubus.de> wrote:
>>
>>How do you ("easily") implement a polymorphic type system for Common
>>Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>>well-known Lisp, such as Scheme) so that you can make any Common
>>Lisp (or Scheme, ...) program be statically type checked?
>
>
> By shadowing defun.
Not quite. The class of programs that can be statically
type checked (via Hindley-Milner or any other technique)
is a strict subset of the class of programs that can be
expressed in Lisp and Scheme.
By shadowing Defun, you can statically typecheck programs
which are statically type-checkable and/or expressible in
languages with static type systems; but there is no way
at all to statically typecheck "any" Common Lisp or Scheme
program, because CL and Scheme can be used to express
programs that do not have static type semantics.
Bear
Ulrich Hobelmann
> You can't make it so, for "any" program -- your are proposing a
> tautology, because you can't statically type check all classes of
> computer programs. But it would be easy to implement, in Lisp,
> a suitable language for embedding with Common Lisp.
It depends on what you consider static checking. In Lisp all functions
have type Lisp -> Lisp, which is a very wide type ;)
If you want to go Hindley-Milner, for instance, you can't type all Lisp
programs in that, maybe.
--
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)
Ron Garret
Ray Dillinger <be...@sonic.net> wrote:
None of those claims are true. All Lisp and Scheme programs can be
statically type checked. Furthermore, all Lisp and Scheme programs have
static type semantics.
It is true that the result of performing a static type check on certain
Lisp programs may be that the program is incorrect with respect to
certain static criteria. It is also true that the static type semantics
of certain Lisp and Scheme programs might not be particularly
interesting or useful. But all that is beside the point. It goes
without saying that even Lisp is subject to the fundamental constraints
of computation. That does not change the fact that it is much easier to
add Hindley-Milner type checking to Lisp than to any other language that
does not natively possess it.
rg
Ron Garret
Matthias Blume <fi...@my.address.elsewhere> wrote:
> Ron Garret <rNOS...@flownet.com> writes:
>
> > In article <3pjj9bF...@news.dfncis.de>,
> > Matthias Buelow <m...@incubus.de> wrote:
> >
> >> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
> >>
> >> >[2] "Most powerful" in the sense that there are features that Lisp has
> >> >that no other language has, and at the same time there are no features
> >> >that any other language has that Lisp does not have (or could not be
> >> >easily implemented within the language).
> >>
> >> How do you ("easily") implement a polymorphic type system for Common
> >> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >> well-known Lisp, such as Scheme) so that you can make any Common
> >> Lisp (or Scheme, ...) program be statically type checked?
> >
> > By shadowing defun.
>
> It is not that easy. Hindley-Milner (as well as many other things)
> depend on certain properties of the language -- in particular that
> there are some things that one canNOT do.
So? (See my response to Bear.)
> There is no language where "everything is expressible"
Who ever said that there was?
rg
Panu Kalliokoski
> Well, I never pass up an invitation to grump and holler. Regardless
>of language, platform or goal, when projects hit three or four million
>lines of code, cancellation rates skyrocket. When we read "Mythical
But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
do in 3M lines of Java/C.
Anyway, I have never been happy with this concept of "project" size.
What constitutes a project? See my rant on the subject at
http://c2.com/cgi/wiki?FactoringLargePrograms (the name was not picked
by me). (But please answer in the NG, because Ward's wiki is nowadays
mostly a closed medium.)
Frank Buss
> You could possibly use Lisp to generate that code for you.
this is possible and I've already used Lisp for a Java project to generate
the database schema for Postgresql and MySQL from the same Lisp source. But
generating C is not worth the trouble for such a small project, because you
have to write many lines of Lisp code to generate C syntax from an abstract
definition. Then it is better to invest the time in the FFI interface to
allow to write Mac and Linux Plugins and Windows ActiveX Plugins (they are
all a bit different) all from the same Lisp code base, but currently I
don't have the time to do it.
Ben
Panu Kalliokoski wrote:
>
> But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
> do in 3M lines of Java/C.
>
> Anyway, I have never been happy with this concept of
> "project" size.
> What constitutes a project? See my rant on the subject at
> http://c2.com/cgi/wiki?FactoringLargePrograms
> (the name was not picked
> by me). (But please answer in the NG, because Ward's
> wiki is nowadays
> mostly a closed medium.)
>
Well, I'm up at 4:00am with the baby, so I'll type a response while I
let the swing try to soothe her back to sleep. I hope this is somewhat
sensible. :)
To start with, I have to disagree with the statement that you can do
more w/ 3 million lines of Lisp/Haskell/(Pick you language) than with
Java/C. In my experience, much of the LoC savings of interpretted
languages comes from the extensive library support, and a briefer
syntax for many things. Once you have a couple hundred thousand lines
of library / toolkit code integrated, the libraries and the syntax get
closer to the interpretted language. There is less of an advantage
then. Compare using standard C++ to using C++ with boost.
As for project size, the large projects I have been involved with are
families of embedded systems with multiple boards, multiple processors
on each board, multiple GUI/s running on their own SPARCs or PCs for
different purposes. They were constructed modularly - all the
components support several product families. When a new product is
created, a new set of requirements come in, and all the components have
to be updated and integrated. So there are a few thousand lines of
code to control thing A, and a couple hundred thousand to control thing
B, and a half-million on the main control board where everything comes
together, and few hundred thousand lines to abstract away system calls.
(So OS's and electronic hardware can change from product to product
and platform to platform withouth changing application code) Different
languages are used in different places, and data is moved through XML
or proprietary binary formats when speed or size is an issue. All this
means that you need 50 - 70 software developers with another 20 people
managing requirements, a whole team managing the nightly builds and
servers and tracking which version of what software components are
working together with which version of what hardware components. (With
all the HW/OS abstraction layers it is possible to detect HW at
powerup, and configure dyamically, but usually a throughput or powerup
timing requirement forces a couple things to be hardcoded)
Communication is vital, and if you end up working a feature with
someone who doesn't understand how to plug a few systems together
you're both doomed to schedule hell.
There are certainly improvements that could be made, and for the most
part the individual components don't get into millions of lines. But
the code is all there in what the customer has shipped to them, and
when the user clicks "go", six million lines of code will execute
several times before the output is achieved. It all needs to have
people who understand the software and how to integrate it with other
software to add features and fix problems.
I guess maybe the world of shrinkwrap software doesn't have many
things like this - I've been doing embedded work for a long time (C++
mostly and sometimes Java). Maybe the skilled people aren't needed so
much for desktop or server apps - someone else would have to speak to
that. I guess if you don't need the best, could you please hire the
worst so they stop ending up on my teams! :) When someone makes a
change in the system and it starts taking 90 milliseconds to do
something with a 65 millisecond deadline, you learn appreciate talented
peers who understand a system top to bottom who can help track that
down.
Kris Cipa
> I don't know if I'm typical but my first experience of lisp was in an
> introductory AI programming course, where lisp was the topic for a
> couple of weeks. In that short time all we learned was about lambda
> expressions and their relation to lisp. After that we did some things
> with lists and that was it. The rest of undergraduate level AI was done
> in Prolog.
>
> >From that kind of introduction by someone who doesn't really know lisp,
> you're not going to develop much enthusiasm, and I didn't.
It is not so much that the course was taught badly - I think it was
fine as far as it goes. It is just that the programming language itself
feels so klunky and basic.
Actually it reminded me of my days coding in BASIC on a Spectrum as a
kid: in both cases you have to go through hoops to make the compiler
happy rather than the compiler making things easy for you. I mean
there's something called parsers, they've been around for years, so why
does the user have to use raw AST to write programs in Lisp? Just like
in old BASICs where you had to number your lines so interpreter can
execute them in the correct order.
Apparently it's so you can obfuscate the code with macros, but come on,
even if you really wanted those (I don't) there must be a better way
than coding in raw syntactic representation!
And of course there's tons of other issue, you can imagine what: the
braindead naming conventions: either cryptic like lambda, car, cdr,
cdaadr, princ and company, or long winded verbosities like
call-with-current-continuation or multiple-value-bind; the almost total
lack of useful libraries or IDEs, the list just goes on.
>From reading the advocay pages I was pointed to etc it seems like
people are into lisp for totally non-technical reasons: they all saw
the light and never went back, they have secret knowledge that others
lack etc. It seems more of a cult than a programming language
community.
So I still don't get what the real technical advantages are.
--
Kris
Paul F. Dietz
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
>
> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you. I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp?
That you have to be asking this question demonstrates that you
really, really don't understand why Lisp is that way.
Look, having a more conventional syntax for Lisp has been tried,
repeatedly, for more than four decades. Each time it's been tried
it's failed to gain any traction. The reason is that the syntax
becomes natural with just a little experience -- it's just a syntax;
it's not there to 'make the compiler happy' -- and the payback
from macros is tremendous.
Paul
Pascal Costanza
> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
>
>>[2] "Most powerful" in the sense that there are features that Lisp has
>>that no other language has, and at the same time there are no features
>>that any other language has that Lisp does not have (or could not be
>>easily implemented within the language).
>
> How do you ("easily") implement a polymorphic type system for Common
> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> well-known Lisp, such as Scheme) so that you can make any Common
> Lisp (or Scheme, ...) program be statically type checked?
That wasn't Ron's claim. He said "implemented within the language" not
"implemented for the language".
It is clear that there are programming language constructs that are
incompatible with each other, in the sense that you cannot have them in
the same language. However, it's comparatively simple to embed
incompatible languages in Common Lisp that you can use each within their
own "world" but, for example, let programs in those different
sublanguages still interact with each other.
ACL2 is a good example because it is a subset of Common Lisp restricted
to purely applicative constructs. Within ACL2, you can only program in
that subset and are not allowed to use constructs with side effects from
the host language. Seems to work very well.
> There are indeed many things that can be (more or less straightforward)
> implemented in, or emulated with (Common) Lisp but your claim that
> there are _no_ features of any other language that cannot be "easily"
> (I'd say, "naturally") expressed in Lisp is a bit strong.
The "easily" part probably refers to the fact that it's particularly
easy to regard programs or program fragments as data. This is an
important feature to make embeddings of different languages in the same
environment work. For example, a type checker is "just" a program that
traverses an s-expression and yields 'acceptable or 'not-acceptable...
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Bradd W. Szonye
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language
> itself feels so klunky and basic.
The core language is definitely minimalist. It does have a few
advantages, however. Once you get accustomed to prefix notation, it's
much easier to read and write complex expressions, largely because
everything is regular. You can often write conditions and loops much
more tersely than you could in a procedural language, without obscuring
the meaning. It's the same thing that attracts some people to C and
Perl, only moreso.
The regular syntax also makes it easy to write Lisp parsers. Coming from
other languages, that may not seem like a big deal, but it's a major
advantage for some users. Easy parsing means that you can create domain-
specific languages easily: With a bit of forethought, you can write
programs in a Lisp-like language tailored to your specific needs. In
most languages, that's difficult enough that it's not worth doing.
> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you.
That shouldn't happen with Lisp, so long as you're using a decent IDE,
and Lisp has some really excellent IDEs -- including the one built into
Emacs. However, an IDE doesn't help unless you know what it can do for
you and how to use it, and as a novice you probably didn't know how to
use Emacs effectively.
> I mean there's something called parsers, they've been around for
> years, so why does the user have to use raw AST to write programs in
> Lisp?
The original Lisp design called for a more traditional parser, but
nobody ever got around to making it, because the users didn't want it.
Traditional parsers make it easier for novices to write programs, but
s-expressions make it easier for experts to write meta-programs --
something that traditional syntax hinders. I've you have any interest in
C++ meta-programs, you'll know what I mean: It's very, very cool stuff,
but tough to write and nearly impossible to understand. Lisp makes that
stuff (relatively) easy.
> Apparently it's so you can obfuscate the code with macros, but come
> on, even if you really wanted those (I don't) ....
If you've only ever used C-style macros, that's understandable. Lisp
macros are more like C++ template meta-programs, without all the angle
brackets and headaches. The difference between Lisp macros and C++
meta-programs is like writing "Hello world" in Perl instead of Java, for
a crude comparison.
> ... there must be a better way than coding in raw syntactic
> representation!
I don't know of a better way of writing meta-programs.
> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
> call-with-current-continuation or multiple-value-bind ....
Eh, Lisp is no better or worse than other languages in this respect.
Compare it to "strxfrm" in C, "bidirectional_iterator" in C++, "$_" in
Perl, or just about anything in COBOL. You just aren't used to it.
> the almost total lack of useful libraries or IDEs ....
Common Lisp has many sophisticated libraries and IDEs, as do some
flavors of Scheme (e.g., PLT Scheme). As I mentioned, Emacs has one of
the best Lisp IDEs; you probably didn't have sufficient training or
experience with it, that's all.
> the list just goes on.
Much of your list is off the mark; while Lisp is different from what
you're used to, the stuff exists.
> From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they have secret knowledge that
> others lack etc.
There's no secret, but some of Lisp's advantages are difficult to
explain to novices, even if they have considerable experience with other
languages. The meta-programming stuff is a good example; except for C++
programmers, not many people know it exists, let alone understand why it
might be useful. Closures are another good example. They package up a
function and a bit of data, which may not seem very important unless you
realize that it's the same basic idea as object-oriented programming
(with a lot less typing). With closures, you don't really need OO
features, because it's almost trivially easy to roll your own objects.
> It seems more of a cult than a programming language community. So I
> still don't get what the real technical advantages are.
People are trying to explain them to you. Try to see past the ugly bits
that scare off novices. I didn't like Lisp either, when I learned it in
college. The parentheses were annoying, the deep expression nesting was
confusing, and overall it seemed like a big hassle compared to C. While
Lisp is still not my /favorite/ language, it's tied for second place.
(Perl is my favorite, and C is my other second-favorite language. I used
to be a C++ nut, but I haven't programmed in it for years, and going
back is a bit daunting.)
--
Bradd W. Szonye
http://www.szonye.com/bradd
Matthias Blume
>> There is no language where "everything is expressible"
>
> Who ever said that there was?
You. You said that there are no features that any other langugage has
that Lisp does not have and which could not easily be implemented
within the language. That claim is just false.
Proof: Pick any feature A. Now consider feature A* defined as:
A* = "A cannot arise"
Yes, you could (assuming Lisp has feature A) implement /another/
language with feature A* using Lisp, but not /in/ Lisp in the sense
that you "add" the feature to Lisp without at the same time removing
other features (namely A).
Matthias
Matthias Blume
> Matthias Buelow wrote:
>
>> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
>>
>>> [2] "Most powerful" in the sense that there are features that Lisp
>>> has that no other language has, and at the same time there are no
>>> features that any other language has that Lisp does not have (or
>>> could not be easily implemented within the language).
>> How do you ("easily") implement a polymorphic type system for Common
>> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>> well-known Lisp, such as Scheme) so that you can make any Common
>> Lisp (or Scheme, ...) program be statically type checked?
>
> That wasn't Ron's claim. He said "implemented within the language" not
> "implemented for the language".
You mean I can use Lisp to implement some /other/ language that has
H-M typing? Well, duh! I can do that using pretty much /any/ language.
> It is clear that there are programming language constructs that are
> incompatible with each other, in the sense that you cannot have them
> in the same language. However, it's comparatively simple to embed
> incompatible languages in Common Lisp that you can use each within
> their own "world" but, for example, let programs in those different
> sublanguages still interact with each other.
I can agree with this paragraph. But Ron's claim was worded much more
strongly -- so strongly in fact that it became false.
Matthias
A.L.
<kristi...@yahoo.co.nz> wrote:
>What's so great about lisp?
>I had to use lisp in college for a course, and it looked like a
>horribly primitive and useless contraption. We even had to use emacs to
>use it, in the 21 century!. I have avoided it ever since. However I
>find more and more people rhapsodizing about how cool Lisp is and what
>an advanced language it supposedly is. I just don't get it: I mean do
>those people claim that we have made no progress in all the years since
>the early days of computing when lisp was used?
>I'd like to know, what's the secret?
>Regards
You don't know because you don't LOVE Lisp. Lisp is greater than
your girlfriend, your mom, your dad, your country and your dog. This
is The Best Thing Ever Invented, and The Best Language That Makes
Everything 20 Times Faster And Easier Than in Any Other Language.
Lisp doesn't need libraries because real Lisper writes everything
himself
How do I know?.. Well... I read comp.lang.lisp
Kapturek62
Paolo Amoroso
"Kris Cipa" <kristi...@yahoo.co.nz> writes:
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
The COMMON-LISP package of Common Lisp has 978 symbols. Does it
qualify as "basic"? What do you mean by "klunky"? Any examples?
> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!
Like?
> call-with-current-continuation or multiple-value-bind; the almost total
> lack of useful libraries or IDEs, the list just goes on.
What problems or limitations have you found in existing Lisp IDEs?
Which one(s) have you tried? Also, which libraries do you
particularly miss?
> From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they have secret knowledge that others
> lack etc. It seems more of a cult than a programming language
> community.
> So I still don't get what the real technical advantages are.
If you think that Lisp is a cult rather than a programming language,
technical advantages are irrelevant. Why do you bother?
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
A.L.
wrote:
>In <1127526780.9...@g14g2000cwa.googlegroups.com> "Ben" <benb...@gmail.com> writes:
>> Well, I never pass up an invitation to grump and holler. Regardless
>>of language, platform or goal, when projects hit three or four million
>>lines of code, cancellation rates skyrocket. When we read "Mythical
>
>But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
>do in 3M lines of Java/C.
>
Have you ever seen 3M lines of Haskell?... 3M lines means about 50
people team, and majority must know programming language very well.
Have you seen 25 Haskell programmers in one place?...
Kapturek62
A.L.
<amo...@mclink.it> wrote:
>
>What problems or limitations have you found in existing Lisp IDEs?
>Which one(s) have you tried? Also, which libraries do you
>particularly miss?
BLAS. Cephes. PVM. MPS.
A.L.
Tayssir John Gabbour
> From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they have secret knowledge that others
> lack etc. It seems more of a cult than a programming language
> community.
Any cult-like resemblances will likely now diminish, as people at
places like Microsoft publicly adopt Lisp.
People used to be rather spooked at the reality distortion fields which
excluded Lisp. Leading to this cult-like behavior, which nearly any
radical non-mainstream group exhibits. Now it's starting to be part of
the distortion field.
Tayssir
Pascal Costanza
> You mean I can use Lisp to implement some /other/ language that has
> H-M typing? Well, duh! I can do that using pretty much /any/ language.
Yes, but not as easily. That's the whole point.
>>It is clear that there are programming language constructs that are
>>incompatible with each other, in the sense that you cannot have them
>>in the same language. However, it's comparatively simple to embed
>>incompatible languages in Common Lisp that you can use each within
>>their own "world" but, for example, let programs in those different
>>sublanguages still interact with each other.
>
> I can agree with this paragraph. But Ron's claim was worded much more
> strongly -- so strongly in fact that it became false.
I don't think so. Maybe it was a little bit vague, but then your
interpretation of what he said is not the only possible one.
Matthias
Ulrich Hobelmann
> Have you ever seen 3M lines of Haskell?... 3M lines means about 50
> people team, and majority must know programming language very well.
> Have you seen 25 Haskell programmers in one place?...
Hm, I don't know the size of GHC, but I'd guess it's quite big. It uses
GCC as the backend, AFAIK, but still does *a lot*. GCC by comparison
was lots of megabytes when I last looked, just the source. Zipped. And
it doesn't do much AT ALL. Oh yes, written in C.
Or look at a Lisp compiling itself. Vastly faster, and with vastly less
source than GCC takes.
Edi Weitz
> To start with, I have to disagree with the statement that you can do
> more w/ 3 million lines of Lisp/Haskell/(Pick you language) than
> with Java/C. In my experience, much of the LoC savings of
> interpretted languages comes from the extensive library support, and
> a briefer syntax for many things.
Which of "Lisp/Haskell/(Pick you language)" is an interpreted
language? And do you really think that there's "extensive library
support" for Lisp and Haskell but not for Java or C? What are you
talking about?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Paolo Amoroso
> On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
[...]
>>Which one(s) have you tried? Also, which libraries do you
>>particularly miss?
>
> BLAS. Cephes. PVM. MPS.
Some starting points:
http://www.stat.umn.edu/users/stat-lisp-devel/msg00133.html (Cephes)
http://lush.sourceforge.net/ (BLAS)
http://www.uni-koeln.de/~a0047/disco93/node6.html (PVM)
I don't know MPS. You may also try Verrazano + CFFI.
Ulrich Hobelmann
Kris Cipa wrote:
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
Hm, sounds like that Scheme class I had in my first semester. There are
other Lisps out there you know. Just like C and Java doesn't only mean
the base language. There are things called libraries. In Lisp there
are also things called macros.
> I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp? Just like
> in old BASICs where you had to number your lines so interpreter can
> execute them in the correct order.
Hm, why do most oh-so-modern platforms (say, J2EE) require me to create
tons of files in raw AST, called XML? Hmmmm...
And do you really think that
foo(bar(a, b, (x+y)*24), c) is that much more readable than
(foo (bar a b (* (+ x y)
24))
c)
even if you remove the indentation. I don't see THE POINT of using that
"cool" syntax, just so you can have a custom parser for that. Seems
like it wasn't enough, either, since C uses another parser (CPP) to
preprocess stuff. Oh, and yacc, lex and other tools also have their own
parsers and create C code. For Java things are similar.
And I don't even want to see how a readable Lisp LOOP expression would
look like in Java...
> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!
And that is? Using Java and lots of XML, oops, raw syntax again, only
with more arbitrary complexity added.
And why use macros when you can use lots of different preprocessors and
code generators instead, only that they don't recognize each others'
syntax, so you can't combine them, as you can with macros.
> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
Oh my god, it's sooo much easier to just do a
Pair foo = bla();
foo.second.first.first.second
than just doing a (cdaadr (bla)), right?
Not to mention calling
someobj.somefunction(new BlaFunction(){
public void fun() { do stuff(); } } );
instead of (somefunction someobj (lambda () do stuff)), because syntax
is cool. Right.
And everybody knows that System.out.println is Good because God says so,
but PRINC is from hell, as are PRINT and FORMAT. Unless you code in C,
then printf is suddenly cool again.
> call-with-current-continuation or multiple-value-bind; the almost total
> lack of useful libraries or IDEs, the list just goes on.
Right. I love having to write "return new Tuple3(a, b, c);" in Java,
and having to extract the values from the tuple, because there are no
multiple values. Greatest. Innovation. Ever. And that's ten years
after Standard ML we're talking here. They should have known.
Oh, and of course continuations are useless, as everybody knows:
http://jakarta.apache.org/commons/sandbox/javaflow/
http://rifers.org/
http://www.theserverside.com/news/thread.tss?thread_id=36594
It's much more fun to have at least three different implementations of
it, that probably aren't too compatible.
>>From reading the advocay pages I was pointed to etc it seems like
> people are into lisp for totally non-technical reasons: they all saw
> the light and never went back, they have secret knowledge that others
> lack etc. It seems more of a cult than a programming language
> community.
I don't know anybody who likes Java, or C#, that also really knows
Smalltalk, or Lisp, but almost everybody in the Lisp camp is really
fluent in C, Java, and probably several other languages. You figure.
> So I still don't get what the real technical advantages are.
I'm afraid I can't help you then. If you don't see advantages, just go
home to the java newsgroup of your choice (or whatever language you
think is much cooler than Lisp).
Julian Squires
On 2005-09-24, Kris Cipa <kristi...@yahoo.co.nz> wrote:
> Apparently it's so you can obfuscate the code with macros, but come on,
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!
This reminds me of another thing of those good old 8bit basic and asm
days. Why obfuscate the code with named functions or symbols instead of
direct addresses for memory mapped registers? It only makes it harder
to see what's going on. Even assembler macros were bad; the only
sensible thing is to program in a machine language monitor.
--
Julian Squires
justinhj
"It is not so much that the course was taught badly - I think it was
fine as far as it goes. It is just that the programming language itself
feels so klunky and basic.
Actually it reminded me of my days coding in BASIC on a Spectrum as a
kid: in both cases you have to go through hoops to make the compiler
happy rather than the compiler making things easy for you. I mean
there's something called parsers, they've been around for years, so why
does the user have to use raw AST to write programs in Lisp? Just like
in old BASICs where you had to number your lines so interpreter can
execute them in the correct order."
If you were taught well I don't think you'd be making the kind of
statements you are. Lisp is far from just an AST. I'd describe it as a
pure uncluttered language rather than a basic one.
"Apparently it's so you can obfuscate the code with macros, but come
on,
even if you really wanted those (I don't) there must be a better way
than coding in raw syntactic representation!
And of course there's tons of other issue, you can imagine what: the
braindead naming conventions: either cryptic like lambda, car, cdr,
cdaadr, princ and company, or long winded verbosities like
call-with-current-continuation or multiple-value-bind; the almost total
lack of useful libraries or IDEs, the list just goes on. "
But macro's are not for obfuscating.. they are for better expressing
what you want your program to do. If you want obfsucation take a look
at any reasonably complex peice of C++ and STL.
cdr and car actually have quite useful properties in that they are
short and they can be combined into caddr, caaddr etc which you cannot
do with the more expressive names 'first' or 'rest'.
The best way to prove yourself right or wrong in this matter is to
write a program that does something interesting in your language of
choice and then in lisp and compare your experiences.
Julian Squires
> Yes, you could (assuming Lisp has feature A) implement /another/
> language with feature A* using Lisp, but not /in/ Lisp in the sense
> that you "add" the feature to Lisp without at the same time removing
> other features (namely A).
This reminds me of the old "irresistable force versus immovable object"
thing. And, of course, you're right. Except that I think Ron's intent
included sublanguages like ACL2. I don't think it's fair to say that
implementing something like that in Lisp is just the same as
implementing it in C. There is an obvious practical difference, and
that is the important point.
Cheers.
--
Julian Squires
Kenny Tilton
Paolo Amoroso wrote:
> A.L. <alew...@kapturek62.com> writes:
>
>
>>On Sat, 24 Sep 2005 15:33:50 +0200, Paolo Amoroso
>
> [...]
>
>>>Which one(s) have you tried? Also, which libraries do you
>>>particularly miss?
>>
>>BLAS. Cephes. PVM. MPS.
>
>
> Some starting points:
>
> http://www.stat.umn.edu/users/stat-lisp-devel/msg00133.html (Cephes)
> http://lush.sourceforge.net/ (BLAS)
> http://www.uni-koeln.de/~a0047/disco93/node6.html (PVM)
>
> I don't know MPS. You may also try Verrazano + CFFI.
Oh, goody, I need a C++ test for my evaluation of vzn (Verrazano). I
will try Cephes. Any Cephes users out there? As far as I can make out,
the main header is qfloat.h? And I see test1, test2, test3... are those
good regression tests or just detritus?
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Matthias Buelow
>> How do you ("easily") implement a polymorphic type system for Common
>> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
>> well-known Lisp, such as Scheme) so that you can make any Common
>> Lisp (or Scheme, ...) program be statically type checked?
>
>You can't make it so, for "any" program -- your are proposing a
>tautology, because you can't statically type check all classes of
>computer programs. But it would be easy to implement, in Lisp,
The poster I responded to made the claim that any language feature
can be "easily" backfitted into Lisp. Upon which I gave the
counter-example of static polymorphic typechecking, which, as I see
it, is not possible (without replacing the compiler, or, for that
matter, "eval"). I'm not saying that one can type-check all possible
computer programs, I'd be satisfied with the subset that typically
can be type-checked in languages that have this feature.
>a suitable language for embedding with Common Lisp.
Please explain. Of course one can write a ML/Haskell/whatever
interpreter in Lisp or Scheme. But that's probably not what you
mean.
mkb.
Ron Garret
Matthias Blume <fi...@my.address.elsewhere> wrote:
Well, if you choose to define "in Lisp" so as to prohibit the removal of
existing features then of course (tautologically in fact) you cannot
implement A* "in Lisp".
But that's a stupid definition because it *is* possible to remove (or at
least effectively hide) features in Lisp. Lisp is specifically designed
to make it easy to implement "other languages" (as you put it) whose
semantics are incompatible with (parts of) Lisp. And indeed there are
many existence proofs of Lisp being used in precisely this way. (In
fact, my original suggestion of implementing HM type checking by
"shadowing defun" is an example of "removing" a feature to replace it
with an incompatible feature.)
(I think I'm beginning to understand the motivation behind some of Erik
Naggum's opinions of the Scheme community.)
rg
Matthias Buelow
>But that's not the way music seems to be going. Instead, we're
>getting MP3's, which have smaller bandwidth but utterly mangle
>any subtle sounds.
I think with consumer bandwidth offerings getting expanded every
year, and disk space being cheap now anyways, mp3 will be succeeded
by flac (preferrably), or a number of proprietary lossless encodings
in some time. At least when consumers are not completely stupid
(ok, not a good chance here.) I at least won't pay for mp3 or similar
losing encodings; when they want to sell me music over the Internet,
then they better offer it in lossless formats (from which I usually
generate mp3s for my own convenience, like stuffing them into the
iPod or so, but that doesn't matter.)
mkb.
Scott G. Miller
> drewc wrote:
>
>> Stefan Ram wrote:
>>
>
>>> Even from the very distance one could here immediatly that
>>> this was not recorded music. So you should go to places where
>>> jazz music is played live -- not listen to records.
>>>
>>> When I heard that music I thought, "What a lie, to suggest
>>> that music can be recorded on technical media!"
>
> Honestly, I think it's more about storage and reproduction issues
> than a recording issue. CD's use something like ten megabytes a
> minute to store a raw sound format; that's really only about a
...snip...
Actually, I think the primary failing of recording/playback systems
today isn't really fidelity. I doubt that most people could honestly
(aka in a double blind test) tell the difference between a live point
audio source and a recorded one.
However, todays recordings often ignore the second aspect that make
"live" lifelike: the complexity of reflected sound. The home theatre
industry is focused in a very marketroid way on selling ever increasing
numbers of surround speakers, but all on a two dimensional plane.
Ambisonics solves the playback part elegantly, but that isn't being
built for end users, and certainly music isn't being recorded that way.
</end ot>
Scott
Ray Dillinger
> So I still don't get what the real technical advantages are.
It's okay; you don't have to. :-)
Bear
Panu Kalliokoski
>>But you can do a whole lot more in 3M lines of Lisp/Haskell than you can
>>do in 3M lines of Java/C.
>Have you ever seen 3M lines of Haskell?... 3M lines means about 50
>people team, and majority must know programming language very well.
>Have you seen 25 Haskell programmers in one place?...
How does one "see" 3M lines of anything?-) No, I haven't tried; the
claim was an extrapolation of experiences with shorter programs.
Pascal Costanza
> Of course one can write a ML/Haskell/whatever
> interpreter in Lisp or Scheme.
Or an interpreter of such a language, but with s-expression syntax, to
avoid parsing. Or a compiler of such a language with s-expression syntax
to Lisp or Scheme. Or a set of macros that effectively perform the
translation from that s-expression-based language to Lisp or Scheme.
Use a full-fledged macro system to perform checks during the translation
process. Use a code walker to determine non-trivial properties of the
code to be checked. Use packages or a module system to define the subset
of Lisp or Scheme that the language is compatible with.
Panu Kalliokoski
> One should never see 3M lines of anything.
My point exactly, and explained on the page FactoringLargePrograms...
another older writing of mine on the subject is
http://c2.com/cgi/wiki?WhatIsaProject
>(while(print(eval(read)))
I find it somehow funny that the expression is missing a parenthese. :)
P
--
personal contact: ate...@iki.fi, +35841 5323835, +3589 85619369
work contact: panu.kal...@helsinki.fi, +35850 3678003
kotisivu (henkkoht): http://www.iki.fi/atehwa/
homepage (technical): http://sange.fi/~atehwa/
A.L.
wrote:
>In <f9maj11911c4sf43f...@4ax.com> A.L. <alew...@kapturek62.com> writes:
Extrapolate linearly?... Sorry, life is more complicated...
A.L.
David Golden
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>>"(sin 0)" is the Cambridge-notation.
>
> When thinking about how to call the whole thing "(sin 0)",
> I thought "It has a nucleus and satellites - so it should
> be called an 'atom'." -- but then, in Lisp, this is exactly
> the opposite of an atom!
Well, the problem stems from "atom" (meaning indivisible
thing: a-tom) being applied by physicists to something
that later turned out to be divisible. D'oh.
Matthias Buelow
> When size and complexity are handled in the right way, they
> disappear.
Unfortunately, they usually aren't handled the right way...
mkb.
Matthias Buelow
>Or an interpreter of such a language, but with s-expression syntax, to
>avoid parsing. Or a compiler of such a language with s-expression syntax
>to Lisp or Scheme. Or a set of macros that effectively perform the
>translation from that s-expression-based language to Lisp or Scheme.
Yes, well.. but that's beside the point since we were talking about
adding features to Lisp in the sense of those features then being
available for any Lisp program, and not just for embedded sub-languages.
It's like pregnancy; either a woman is pregnant, or she isn't.
There's no "somewhat" (partially) pregnant.
Apart from that, after a number of years of experimenting, I
personally have come to the conclusion that I prefer a portfolio
of distinct languages with (potentially very different) specialized
syntax+semantics, for different application domains, to a
stuff-it-all-into-one language (such as Common Lisp attempts to be,
at least theoretically). It's a different philosophy and one that
is, imho, more successful.
mkb.
Ron Garret
Matthias Blume <fi...@my.address.elsewhere> wrote:
> Pascal Costanza <p...@p-cos.net> writes:
>
> > Matthias Buelow wrote:
> >
> >> In comp.lang.lisp Ron Garret <rNOS...@flownet.com> wrote:
> >>
> >>> [2] "Most powerful" in the sense that there are features that Lisp
> >>> has that no other language has, and at the same time there are no
> >>> features that any other language has that Lisp does not have (or
> >>> could not be easily implemented within the language).
> >> How do you ("easily") implement a polymorphic type system for Common
> >> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >> well-known Lisp, such as Scheme) so that you can make any Common
> >> Lisp (or Scheme, ...) program be statically type checked?
> >
> > That wasn't Ron's claim. He said "implemented within the language" not
> > "implemented for the language".
>
> You mean I can use Lisp to implement some /other/ language that has
> H-M typing? Well, duh! I can do that using pretty much /any/ language.
Of course you can. But in any other language it's hard. In Lisp it's
(comparatively) easy. For example, the language for which you implement
HM typing could be a subset or minor variant of Lisp. Lisp includes
features that make it easy to implement such subsets and minor variants,
and in this regard Lisp is unique.
> > It is clear that there are programming language constructs that are
> > incompatible with each other, in the sense that you cannot have them
> > in the same language. However, it's comparatively simple to embed
> > incompatible languages in Common Lisp that you can use each within
> > their own "world" but, for example, let programs in those different
> > sublanguages still interact with each other.
>
> I can agree with this paragraph. But Ron's claim was worded much more
> strongly -- so strongly in fact that it became false.
The truth or falseness of my claim hinges entirely on one's
interpretation of the word "easily". Reasonable people may differ on
this, but since the claim has a subjective element you can't write it
off as objectively false.
rg
Pascal Costanza
> In comp.lang.lisp Pascal Costanza <p...@p-cos.net> wrote:
>
>>Or an interpreter of such a language, but with s-expression syntax, to
>>avoid parsing. Or a compiler of such a language with s-expression syntax
>>to Lisp or Scheme. Or a set of macros that effectively perform the
>>translation from that s-expression-based language to Lisp or Scheme.
>
> Yes, well.. but that's beside the point since we were talking about
> adding features to Lisp in the sense of those features then being
> available for any Lisp program, and not just for embedded sub-languages.
Some people were talking about that, others were not.
> It's like pregnancy; either a woman is pregnant, or she isn't.
> There's no "somewhat" (partially) pregnant.
Yes, there is. That's why some think that abortion is acceptable. (Not
that I know how this would be related to the topic at hand... ;)
> Apart from that, after a number of years of experimenting, I
> personally have come to the conclusion that I prefer a portfolio
> of distinct languages with (potentially very different) specialized
> syntax+semantics, for different application domains, to a
> stuff-it-all-into-one language (such as Common Lisp attempts to be,
> at least theoretically). It's a different philosophy and one that
> is, imho, more successful.
a) If that works well for you, go ahead.
b) Even if that works well for you, that doesn't negate the claim about
the embeddability of language features in Lisp.
c) Just out of interest: Do you never need to interoperate between
applications developed in different languages? I am asking because I
think a host language that eases embedding of specialized languages also
eases interoperability. (This is not a rhetorical question.)
Ron Garret
Matthias Buelow <m...@incubus.de> wrote:
> In comp.lang.lisp Christopher C. Stacy <cst...@news.dtpq.com> wrote:
>
> >> How do you ("easily") implement a polymorphic type system for Common
> >> Lisp (e.g., Hindley-Milner style), within Common Lisp (or any other
> >> well-known Lisp, such as Scheme) so that you can make any Common
> >> Lisp (or Scheme, ...) program be statically type checked?
> >
> >You can't make it so, for "any" program -- your are proposing a
> >tautology, because you can't statically type check all classes of
> >computer programs. But it would be easy to implement, in Lisp,
>
> The poster I responded to made the claim that any language feature
> can be "easily" backfitted into Lisp. Upon which I gave the
> counter-example of static polymorphic typechecking, which, as I see
> it, is not possible (without replacing the compiler, or, for that
> matter, "eval").
You say "without replacing the compiler" as if replacing the compiler
was difficult. And in most languages it is, but in Lisp it's not. In
fact, it is easy to replace the compiler. It is even easy to replace
parts of the compiler while retaining other parts. That's exactly what
macros do.
> I'm not saying that one can type-check all possible
> computer programs, I'd be satisfied with the subset that typically
> can be type-checked in languages that have this feature.
>
> >a suitable language for embedding with Common Lisp.
>
> Please explain. Of course one can write a ML/Haskell/whatever
> interpreter in Lisp or Scheme. But that's probably not what you
> mean.
It doesn't matter. There are many options available:
1. Transparent type checking that operates on Lisp programs to the
extent possible and throws up its hands on cases that it can't handle.
2. Type checking on a subset or slightly modified dialect of Lisp that
is more amenable to being type checked.
3. A complete embedding of an entirely different language specifically
designed for type checking (with or without a new surface syntax).
There are probably others. My claim is: whatever strategy you choose,
it will be vastly easier to implement that strategy in Lisp than it will
be to implement that strategy in any other language (except, of course,
in the trivial case where the language you choose already has the
feature built in, in which case the effort is obviously zero).
rg
Matthias Buelow
Hmm, the rage today seem to be CORBA or XML-RPC style stuff. Not
that I want to advocate that in general but I'd think the problem
is language-independent and would be the same no matter if you use
Lisp, or Java, or ML, or whatever (although using CORBA with ML is
a bit stretching my imagination atm. but could probably be done
by deriving structures+their signatures from the IDL or whatever.)
mkb.
Tayssir John Gabbour
> In comp.lang.lisp Pascal Costanza <p...@p-cos.net> wrote:
> >Or an interpreter of such a language, but with s-expression syntax, to
> >avoid parsing. Or a compiler of such a language with s-expression syntax
> >to Lisp or Scheme. Or a set of macros that effectively perform the
> >translation from that s-expression-based language to Lisp or Scheme.
>
> Yes, well.. but that's beside the point since we were talking about
> adding features to Lisp in the sense of those features then being
> available for any Lisp program, and not just for embedded sub-languages.
> It's like pregnancy; either a woman is pregnant, or she isn't.
> There's no "somewhat" (partially) pregnant.
A person can have blonde hair, a "feature" they remove by religiously
dyeing it blue.
And still, that person may be "partially" blonde. ;)
> Apart from that, after a number of years of experimenting, I
> personally have come to the conclusion that I prefer a portfolio
> of distinct languages with (potentially very different) specialized
> syntax+semantics, for different application domains, to a
> stuff-it-all-into-one language (such as Common Lisp attempts to be,
> at least theoretically). It's a different philosophy and one that
> is, imho, more successful.
Lisp is a tool. Not a philosophy. The only philosophizing Lisp does is
in some AI lab.
Many Lisp users are fluent in multiple programming languages, and are
more than eager to honestly opine which tool is best for your job, and
any Lisp gotchas to watch out for.
http://lisp.tech.coop/Lisp%20Gotchas
I understand skepticism is required in computer "science," as it
features so many reality distortion fields and false advertising. But
that does not mean we should make grand claims about its Philosophy, or
make assumption-laden "proofs" claiming Lisp is too powerful to ever
make a tender chicken. Because that only adds to the reality distortion
field.
Tayssir
Pascal Costanza
In an integrated environment, you can easily pass values unchanged from
one sublanguage to another one. With RPC-style approaches, you will get
overhead and/or semantical issues with serialization/deserialization. So
I think there's an important difference here.
Jon Harrop
> Ron Garret <rNOS...@flownet.com> writes:
>> Who ever said that there was?
>
> You. You said that there are no features that any other langugage has
> that Lisp does not have and which could not easily be implemented
> within the language. That claim is just false.
Indeed, and that incorrect statement is the most commonly cited
justification for using Lisp. Beyond that there is also the implication
that Jo-coder can actually implement any language feature himself.
IMHO, Lisp has a huge number of advantages over assembler and C. So if
they're your alternatives then go for Lisp. If you have the freedom to
choose any language then look at something a little more modern...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Edi Weitz
[Content garbage-collected.]
Hmm, first the bloke who started this thread, then Matthias Buelow
resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.
Is this Troll Day, or what? Do you guys all have one big boot camp
with free Internet access? Well, I hope you have fun over there.
What I don't understand, though, is the following: If it's so obvious
that Lisp is crap why are you still hanging around here? Trying to
save young, innocent souls? Or are the c.l.l inhabitants simply too
troll-friendly?
Sigh,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
M Jared Finder
>
> It is not so much that the course was taught badly - I think it was
> fine as far as it goes. It is just that the programming language itself
> feels so klunky and basic.
> Actually it reminded me of my days coding in BASIC on a Spectrum as a
> kid: in both cases you have to go through hoops to make the compiler
> happy rather than the compiler making things easy for you. I mean
> there's something called parsers, they've been around for years, so why
> does the user have to use raw AST to write programs in Lisp? Just like
> in old BASICs where you had to number your lines so interpreter can
> execute them in the correct order.
>
> even if you really wanted those (I don't) there must be a better way
> than coding in raw syntactic representation!
On the contrary, Lisp is the only language where you rarely write raw
syntax trees, because it you can easily add abstractions to it.
In fact, Lisp is the only language where all the following statements
are true:
1. The rules for parsing text into a syntax tree are extremely simple.
(It can be spec'd informally in under a page)
2. The rules for evaluating the raw syntax tree are extremely simple.
(It can be spec'd informally in under a page)
3. You are not limited to evaluating only raw syntax tree.
4. You are not limited to parsing using only the built in rules.
And it is entirely because of macros that this is the case. In
addition, Lisp has many other nice properties:
5. The language is interactive. You can test code as you write it.
6. The language is (usually) natively compiled. Code is output that is
fast and small.
7. The whole language is always available. In particular, 3 and 4 are
done using existing code.
All these sound like good properties to have, right? And Lisp has all
of them (and has had them since the mid-80s). But somehow, no other
language supports even five of these seven properties. Other so-called
"modern, high-level languages" support from one of these properties
(Java and C# get 6, but only with JIT compilers) to two of them (C++
gets 3 and 6) to three or four of them (Python gets 1, 2, and 5; 6 is
debatable).
As an example, when you write the following in C#, you're using the
built in "foreach" keyword:
foreach( string s in strings ) {
Console.WriteLine( s );
}
But when you write the comparable code in Lisp, you're using the library
level "dolist":
(dolist (s strings)
(write-line s))
The raw syntax tree this represents is a lot bigger:
(block nil
(let ((#:n-list4423 strings))
(tagbody
#:start4424
(if (not (endp #:n-list4423))
(progn
nil
(let ((s (car #:n-list4423)))
(setq #:n-list4423 (cdr #:n-list4423))
(tagbody (write-line s)))
(go #:start4424))
nil)))
nil)
Concepts that are built in to other languages can be added to Lisp by
any programmer. Imagine if you could add the changes from C# 2.0 and
3.0 to C# 1.0 without requiring a new compiler or a new runtime.
> And of course there's tons of other issue, you can imagine what: the
> braindead naming conventions: either cryptic like lambda, car, cdr,
> cdaadr, princ and company, or long winded verbosities like
> call-with-current-continuation or multiple-value-bind;
These are true, but extremely easy to fix. Fixes range from
instantaneous Here's a fix for lambda, call-with-current-continuation,
and multiple-value-bind:
(defmacro fn (&rest args) `(lambda ,@args))
(defmacro call/cc (&rest args) `(call-with-current-continuation,@args))
(defmacro mv-bind (&rest args) `(multiple-value-bind ,@args))
> or IDEs, the list just goes on.
I'd say that 90% of what an IDE is used for can be done better with
macros and an interactive environment. Out of the remaining 10%, 5% can
be done just fine with Emacs and Slime.
> the almost total lack of useful libraries
This is true. The only problem I have currently with Lisp is the lack
of libraries. But with CFFI and Veranzzno (or however it's spelled) all
C and C++ libraries should now be Lisp libraries as well.
-- MJF
Peter Seibel
> Matthias Blume wrote:
>
>> You mean I can use Lisp to implement some /other/ language that has
>> H-M typing? Well, duh! I can do that using pretty much /any/
>> language.
>
> Yes, but not as easily. That's the whole point.
I think Pascal is being too brief here, perhaps because he has made
the real point elsewhere in the thread. But I'll reiterate it: The
difference between Lisp and most other languages is that while you can
use any language to implement an interpreter or compiler for another
language that has H-M typing (or whatever other language feature you
want), in Lisp you can easily implement an interpreter or compiler for
such a langugae in a way that allows programs written in that language
to be embedded in Lisp programs, passing data back and forth between
the embedded program and the containing Lisp world.
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Thomas F. Burdick
> On Sat, 24 Sep 2005 20:51:31 +0100, Jon Harrop <use...@jdh30.plus.com> wrote:
>
> [Content garbage-collected.]
>
> Hmm, first the bloke who started this thread, then Matthias Buelow
> resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.
>
> Is this Troll Day, or what? Do you guys all have one big boot camp
> with free Internet access? Well, I hope you have fun over there.
>
> What I don't understand, though, is the following: If it's so obvious
> that Lisp is crap why are you still hanging around here? Trying to
> save young, innocent souls? Or are the c.l.l inhabitants simply too
> troll-friendly?
Ron Garret is starting to understand Erik Naggum ... if there was ever
an objective proof that c.l.l is too troll-friendly :-)
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Pascal Bourguignon
> In <3M-20050...@ram.dialup.fu-berlin.de> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> One should never see 3M lines of anything.
>
> My point exactly, and explained on the page FactoringLargePrograms...
> another older writing of mine on the subject is
> http://c2.com/cgi/wiki?WhatIsaProject
>
>>(while(print(eval(read)))
>
> I find it somehow funny that the expression is missing a parenthese. :)
The Bug/LoC increases when the LoC decreases.
It also increases when the LoC increases, you neet to have a medium LoC/function.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Thomas F. Burdick
> It is true that the result of performing a static type check on certain
> Lisp programs may be that the program is incorrect with respect to
> certain static criteria.
And in such a case, it would be great (IMO) to have a compiler that
would tell you that, *and* still compile the program, because...
> It is also true that the static type semantics
> of certain Lisp and Scheme programs might not be particularly
> interesting or useful.
However, in the last 10 years there has been a lot of promising work
in type theory. There are funky static type systems that let you
reason about some interesting aspects of programs, but aren't all
terribly well suited to having a general purpose programming language
based on them -- because they have some weird restrictions or
properties. Type theory is only going to advance, we're not going to
learn less about it as time goes on -- so eventually we'll have some
(static) type systems that are really practically useful. I think the
Lispy (or at least CMU-Lispy) approach of noninterfereing static type
checking will really shine then.
> But all that is beside the point. It goes
> without saying that even Lisp is subject to the fundamental constraints
> of computation. That does not change the fact that it is much easier to
> add Hindley-Milner type checking to Lisp than to any other language that
> does not natively possess it.
No doubt. Well, maybe Smalltalk.
Matthias Buelow
>Hmm, first the bloke who started this thread, then Matthias Buelow
>resurfaces, and now Dr. "Flying Frog" Harrop is back again as well.
>Is this Troll Day, or what? Do you guys all have one big boot camp
>with free Internet access? Well, I hope you have fun over there.
Maybe you should come to understand that you haven't rented Usenet
and if you don't like the discussions, then simply stop reading.
mkb.
Thomas F. Burdick
> In article <m2hdcad...@hanabi.local>,
> Matthias Blume <fi...@my.address.elsewhere> wrote:
>
> > You mean I can use Lisp to implement some /other/ language that has
> > H-M typing? Well, duh! I can do that using pretty much /any/ language.
>
> Of course you can. But in any other language it's hard. In Lisp it's
> (comparatively) easy. For example, the language for which you implement
> HM typing could be a subset or minor variant of Lisp. Lisp includes
> features that make it easy to implement such subsets and minor variants,
> and in this regard Lisp is unique.
And the "other language" can probably call back and forth with the
host Lisp, sharing objects and doing things to them, which is all
there is to Lisp. So in effect, it can be perfectly integrated and
quite seamless.