Python has readable syntax, a huge library, and bindings for what
seems like every major in linux. Perl has CPAN. It seems with those
languages if you want to do something all you have to do is import
functionality from a library someone had written and use that.
In lisp you'd have to "roll your own".
Why should I keep on learning lisp when there are python and perl?
> Why should I keep on learning lisp when there are python and perl?
You should not.
From: Don Geddis
Subject: Re: Why stay with lisp when there are python and perl?
Date:
Message-ID: <87d51icyzv.fsf@geddis.org>
······@gmail.com wrote on 2 May 2007 18:20:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
Oh man, this is sweet. I didn't realize that all algorithms that could ever
be conceived had already been implemented in a library somewhere, and one
need only access the library and call the correct predefined function.
Awesome!
Kind of reminds me of David Brin's "Uplift" series of sci-fi books, where all
the knowledge of all the races in the universe was stored in a giant shared
universal library. "Science", in that universe, was basically the same as
being a research librarian, getting good at looking through the library for
what you needed. The answer was always there, but the trick was finding it.
At least, until those pesky humans came around, and started doing original
research on their own...
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Here's a suggestion for a new animal, if some new ones get created or evolve:
something that stings you, then laughs at you.
-- Deep Thoughts, by Jack Handey
······@gmail.com writes:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
Obviously enough, *you* shouldn't. I wouldn't get too worked up about
the reasons.
······@gmail.com wrote:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
As some have said, who's forcing you?
As they left out: there is one perfect programming language. Lisp is
not it, but its the next best thing. While most languages let you write
programs, the Lisp family makes it easy to write both programs and
languages.
Most languages support
- a "preprocessing" language (e.g. including files, "macro" substitutions)
- a compiled language
- some automated code generation (from simple loop structures to C++
classes and templates)
- modifying how code is compiled (e.g. compiler flags)
Each of these stages is generally a separate language with its own
quirks, capabilities, and syntax.
Lisp uses a unified syntax for
- loading and compiling files
- modifying code as it is read (read macros)
- expressing code
- modifying code (macros)
- modifying how code is compiled (compiler macros)
- changing code at runtime (e.g. eval)
Do you see my bias?
It's a far cry from CTAN/CPAN, but the ASDF-Install page has a decent
selection of libraries.
http://www.cliki.net/ASDF-Install
- Daniel
Who's tired of fighting C/C++ all day.
P.S. Lisp isn't the fastest language around (not as many people tuning
it), but it generally compares favorably to Perl and Python and even
Java. http://shootout.alioth.debian.org/
On May 3, 3:20 am, ······@gmail.com wrote:
> Python has readable syntax,
BS
>a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
Python & Perl might give you some headstart but whenever you'll make
something nontrivial, when your application
will need to be customized in real time, when you'll have to make
changes of your architecture, when you need to make your code faster
baby you gonna be in deep shit called big ball mud
http://www.laputan.org/mud/mud.html#BigBallOfMud.
They you 'll cry for readable syntax, the most powerfull Object
Oriented system called CLOS, data is code/code is data and lisp
Macros.But it'll be too late , Guido already shot you at your feet,
you're crippled for good.
cheers
bobi
On May 3, 2:20 am, ······@gmail.com wrote:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
This is great news, which I've been waiting for for some time. All
programs have now been written. rmgroups will be issued for all
programming-related newsgroups this afternoon. Anyone currently
working as a programmer should report to their local office of the
ministry for reconstruction and reallocation.
--tim
I'm glad I sold my soap stocks.
On May 3, 11:16 am, Tim Bradshaw <··········@tfeb.org> wrote:
> On May 3, 2:20 am, ······@gmail.com wrote:
>
> > Python has readable syntax, a huge library, and bindings for what
> > seems like every major in linux. Perl has CPAN. It seems with those
> > languages if you want to do something all you have to do is import
> > functionality from a library someone had written and use that.
>
> This is great news, which I've been waiting for for some time. All
> programs have now been written. rmgroups will be issued for all
> programming-related newsgroups this afternoon. Anyone currently
> working as a programmer should report to their local office of the
> ministry for reconstruction and reallocation.
>
> --tim
>
> I'm glad I sold my soap stocks.
And I was working my ass for nothing, where could I find my app
written?
Antoan
> --tim
>
> I'm glad I sold my soap stocks.
I can just see how my last thoughts as they drag me off to be rendered
down will be, "If only, I'd sold my soap stocks." ;) .
Some entity, AKA ······@gmail.com,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
>
For the same reason you do not want to now how to grow grapes and
make wine when you can get a $3 bottle from a supermarket.
Cor
--
The biggest problem LISP has is that it does not appeal to dumb people
If this failed to satisfy you try reading the Hyper-Spec or woman frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read the mailpolicy before mailing http://www.clsnet.nl/mail.html
From: Slava Akhmechet
Subject: Re: Why stay with lisp when there are python and perl?
Date:
Message-ID: <87odl2ir92.fsf@gmail.com>
Because Lisp is the asymptote.
--
Regards,
Slava Akhmechet.
Some entity, AKA ······@gmail.com,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
>
For the same reason you do not want to now how to grow grapes and
make wine when you can get a $3 bottle from a supermarket.
Cor
--
The biggest problem LISP has is that it does not appeal to dumb people
If this failed to satisfy you try reading the Hyper-Spec or woman frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read the mailpolicy before mailing http://www.clsnet.nl/mail.html
Nameless wrote:
«
Python has readable syntax, a huge library, and bindings for what
seems like every major in linux. Perl has CPAN. It seems with those
languages if you want to do something all you have to do is import
functionality from a library someone had written and use that.
In lisp you'd have to "roll your own".
Why should I keep on learning lisp when there are python and perl?
»
You question is a valid question. Unfortunately, so far in the 14
replies in the thread, vast majority are one-liner drivels from
reactionary lisp fuckheads, many of which long time dwellers of
comp.lang.lisp. A common scene in any programing newsgroup. They feel
attacked, reasonably by your irrespective and incentive tone, and they
have the need to sputter drivel back, to entertain themselves. (I wish
perl and python programers take a glimpse of that thread to realize
what computing factions are driveling behind each other's back)
Although your message is written in a taunting style, but it has a
valid point, and in fact is a Frequently Ask Question among the vast
majority of programers in the computing industry. Namely, today,
languages like Perl, PHP, and to a lesser degree Python, are so
popular, and ubiquitous, widely deployed and widely demanded in the
job market, and also, that these languages in general and in
comparison to Lisp, have far wide library support and as well as
community support, and also, that these comparatively young languages
are relatively high-level modern languages, that they are at a level
above C, Java, making them ideal for saving programer's time as does
lisp.
So, what are some reasons, if any, should today's programer invest
time into another language lisp (especially it has trivial percentage
in programing job market), while not using the time, to perhaps master
a industrial language they already know, such as Perl, or even venture
into another language like Python, PHP or the new kid on the block
Ruby?
So far, “D Herring” and “fireblade/bobi” has given their personal take
on this question. Lars Rune Nøstdal, provided a link
http://wiki.alu.org/The_Road_to_Lisp_Survey that details lispers's
stories on why lispers lisp.
Please allow me to give my take, and i believe it is a most important
_technical_ reason, why, Perl, Python, etc languages today simply
cannot replace lisp. And why, if you are a programer with serious
intention of refining your craft, then learning lisp is a good
investment. (one non-technical reason in learning lisp, is that the
widely popular programer's text editor emacs has lisp embedded as its
extension language. As a coder, knowing emacs and lisp, will enpower
you greatly in the long term.)
I think the one most important techincal aspect, that lisp is in fact
superior and cannot be replaced by the current crop of high-level
languages, is the peculiar fact that the language deals with symbols.
Namely, sometimes called symbolic computing.
I have written a exposition on this issue before. It is archived at
this page:
“What is Expressiveness in a Computer Language”
http://xahlee.org/perl-python/what_is_expresiveness.html
at the section Symbolic Computation.
There are many “papers” or articles that address the question of what
does it mean when someone says lisp is a symbolic language. In my
opnion, they are all fuzzy, or filled with academic jargons that is
practically and most likely theoretically useless. In the following
exposition, you will see what lisp's “symbolic computation” in a way
that makes you understand.
I excerpt the section below.
SYMBOLIC COMPUTATION
Lisp differs from most imperative programing languages in that it
deals with symbols. What does this mean?
In imperative languages, a value can be assigned a name, and this name
is called a variable. For example, “x=3”, and whenever this “name” is
encountered, it is evaluated to its value. It does not make any sense,
to have variables without a assigned value. That is, the “x” is not
useful and cannot be used until you assign something to it.
However, in lisp, there is a concept of Symbols. As a way of
explanation, a “variable” needs not to be something assigned of a
value. Symbols can stand by themselves in the language. And, when a
symbol is assigned a value, the symbol can retain its symbolic form
without becoming a value.
This means that in lisp, “variables” can be manipulated in its un-
evaluated state. The situation is like the need for the “evaluate”
command in many languages, where the programer can built code as
strings and do “evaluate(myCodeString)” to achieve meta-programing.
For example, in imperatives languages once you defined “x=3”, you
cannot manipulate the variable “x” because it gets evaluated to 3
right away. If you want, you have to build a string “"x"” and
manipulate this string, then finally use something like
“evaluate(myCodeString)” to achieve the effect. If the imperative
language does provide a “evaluate()” function, its use breaks down
quickly because the language is not designed for doing it. It's
extremely slow, and impossible to debug, because there lacks
facilities to deal with such meta programing.
In lisp, variable's unevaluated form are always available. One just
put a apostrophe ' in front of it. In “x=3”, the x is a variable in
the contex of the code logic, x is a name of the variable in the
context of meaning analysis, and x is a symbol in the context of the
programing language. This Symbols concept is foreign to imperative
languages. It is also why lisp are known as symbolic languages. Such
makes meta-programing possible.
The power of symbolic processing comes when, for example, when you
take user input as code, or need to manipulate math formulas, or
writing programs that manipulates the source code, or generate
programs on the fly. These are often needed in advanced programing
called Artificial Intelligence. This is also the reason, why lisp's
“macro” facility is a powerful feature unlike any so-called “pre-
processors” or “templates” in imperative languages.
Mathematica for example, is sometimes known as a Computer Algebra
System. It too, works with symbols in the language. They can be
manipulated, transformed, assigned a value, evaluated, hold
unevaluated etc.
One way for a imperative programer to understand symbols, is to think
of computing with strings, such as which Perl and Python are well
known for. With strings, one can join two strings, select sub strings,
use string pattern (regex) to transform strings, split a string into a
list for more powerful manipulation, and use “evaluate()” to make the
string alive. Now imagine all these strings need not be strings but as
symbols in the language, where the entire language works in them and
with them, not just string functions. That is symbolic computation.
Here we see, a expressibility unseen in non-lisp family of languages.
--------------------------
End excerpt.
(if there is some demand, i will add a concrept, little programing
example, that shows, how lisp's symbols and macros concepts, set it
apart from new scripting languages)
This lisp's symbol concept, as far as i know, does not exist in some
other high-level functional programing languages such as Haskell. I'm
not familiar with many functional languages except Lisp and
Mathematica. I'm curious, as to how Haskell, which itself is quite
with capable of symbolic computation i think, deals with it even
though the language doesn't employ the concep of lisp's symbols per
se.
Xah
···@xahlee.org
∑ http://xahlee.org/
Xah Lee wrote:
> Nameless wrote:
> «
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
> »
>
> You question is a valid question. Unfortunately, so far in the 14
> replies in the thread, vast majority are one-liner drivels from
> reactionary lisp fuckheads,...
We prefer "The Savages of CLL".
Notwithstanding my recent oratory on innocent-till-proven-guilty, well,
the OP has not responded to anything -- Guilty! Guilty! Guilty!* And I
think you miss an important point: the OP was clear trollbait in tone,
even if offered in good faith. The baying of the hounds could easily
have led to, "OK, sorry, that sure does sound like a troll doesn't it?
Lemme try again...".
Nice encomium on Lisp, but my guess is Franz plants these trolls on
c.l.l. whenever it sees the hype machine spinning down.
:)
kt
* Gary Trudeau, in re AG John Mitchell, who is about to be joined by AG
Gonzalez in the answer to a trivia question. k
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
QUOTE
Python has readable syntax, a huge library, and bindings for what
seems like every major in linux. Perl has CPAN. It seems with those
languages if you want to do something all you have to do is import
functionality from a library someone had written and use that.
In lisp you'd have to "roll your own".
Why should I keep on learning lisp when there are python and perl?
UNQUOTE
I can see where this guy is coming from (though I can't find the
original post any more (?)).
See my remarks on the Lisp for the Twenty First Century
http://www.lambdassociates.org/lC21.htm
for our take on this one.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> See my remarks on the Lisp for the Twenty First Century
> http://www.lambdassociates.org/lC21.htm
Anyone who didn't love lisp in the 20th century has no heart.
Anyone who still loves it in the 21st, has no head.
On 2007-05-04 11:32:14 -0400, Paul Rubin <·············@NOSPAM.invalid> said:
> Anyone who didn't love lisp in the 20th century has no heart.
> Anyone who still loves it in the 21st, has no head.
By the same logic we should all be conservative Republicans. Given this
implication, I'll stick with lisp, thanks.
Mark Tarver wrote:
> QUOTE
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
> UNQUOTE
>
> I can see where this guy is coming from (though I can't find the
> original post any more (?)).
>
> See my remarks on the Lisp for the Twenty First Century
>
> http://www.lambdassociates.org/lC21.htm
>
> for our take on this one.
I am curious: What is "lambda calculus consistency?" A quick google
search doesn't give a lot of results...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 4 Mai, 12:12, Pascal Costanza <····@p-cos.net> wrote:
> Mark Tarver wrote:
> I am curious: What is "lambda calculus consistency?" A quick google
> search doesn't give a lot of results...
Perhaps "referential transparency" is meant?
Ingo Menger wrote:
> On 4 Mai, 12:12, Pascal Costanza <····@p-cos.net> wrote:
>> Mark Tarver wrote:
>
>> I am curious: What is "lambda calculus consistency?" A quick google
>> search doesn't give a lot of results...
>
> Perhaps "referential transparency" is meant?
I guess Mark would have said "referential transparency" if he meant
referential transparency. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 4 May, 11:12, Pascal Costanza <····@p-cos.net> wrote:
> Mark Tarver wrote:
> > QUOTE
> > Python has readable syntax, a huge library, and bindings for what
> > seems like every major in linux. Perl has CPAN. It seems with those
> > languages if you want to do something all you have to do is import
> > functionality from a library someone had written and use that.
>
> > In lisp you'd have to "roll your own".
>
> > Why should I keep on learning lisp when there are python and perl?
> > UNQUOTE
>
> > I can see where this guy is coming from (though I can't find the
> > original post any more (?)).
>
> > See my remarks on the Lisp for the Twenty First Century
>
> >http://www.lambdassociates.org/lC21.htm
>
> > for our take on this one.
>
> I am curious: What is "lambda calculus consistency?" A quick google
> search doesn't give a lot of results...
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/- Hide quoted text -
>
> - Show quoted text -
Well being able to apply a 3-place function like subst to a single
argument and get a function. In lambda calculus all functions are 1-
place and currying is allowed. But in CL this doesn't work.
(2-) (SUBST 1)
APPLY: too few arguments given to SUBST
That was calling the inbuilt Lisp in Qi (Lisp system functions are in
uppercase).
or try
(3-) ((SUBST [1 2 3]) [4 5 6])
error: Odd application; [1 2 3] to [4 5 6]
but in Qi itself
(4-) ((append [1 2 3]) [4 5 6])
[1 2 3 4 5 6]
(5-) (subst 1)
#<FUNCTION :LAMBDA [X11993] #'[LAMBDA [X11994] [subst X11992 X11993
X11994]]>
If you want to use the simply typed lambda calculus as part of the
type theory for your language you need your system to be be consistent
with lambda calculus in supporting currying throughout your entire
program. Following lambda calculus through consistently also enables
the programmer to eliminate discrepancies like having to use FUNCALL
in certain higher-order functions.
Mark
Mark Tarver wrote:
> If you want to use the simply typed lambda calculus as part of the
> type theory for your language you need your system to be be consistent
> with lambda calculus in supporting currying throughout your entire
> program. Following lambda calculus through consistently also enables
> the programmer to eliminate discrepancies like having to use FUNCALL
> in certain higher-order functions.
OK, I see.
Does this mesh well with optional, rest and keyword arguments?
For example, if I have something like ((lambda (x y . rest) ...) 3 4 5),
how does the runtime system know that the function is "done" and should
be evaluated?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 4 May, 14:03, Pascal Costanza <····@p-cos.net> wrote:
> Does this mesh well with optional, rest and keyword arguments?
In short no - currying does not mesh with optional, rest and keyword
arguments as used in Lisp and you cannot really use the simply typed
lambda calculus with that approach. If you want to go in that
direction and have typing then you need a special type theory. I
explored such a theory in ILC 2002 and tried to formalise what CL
needed to be type checked and you can find it the paper here
www.lambdassociates.org/studies/polyadic.pdf
The conclusion of that paper was
__________________________________________________________
Polyadic functions are a useful part of functional programming
practice and their utilisation is integral to Common Lisp. Polyadic
functions, including both infinitary polyadic functions and polyadic
functions with optional arguments, are capable of being organised
within a formal type theory. However a price of treating polyadic
functions as first class objects is that lambda calculus and its type
theory is no longer the theoretical foundation for functional
programming, and partial applications and currying disappear.
However from the perspective of this paper, the abandonment of both
these features is a logical consequence of taking polyadicity
seriously. It is false to say that Common Lisp lacks a type theory.
It is more accurate to say that the language has a type theory whose
foundations are as different from the standard one as non-Euclidean
geometry is from Euclidean and whose differences need to be enlarged
and understood.
______________________________________________________________
But in Qi I followed the orthodox line and remained firmly Euclidean!
> how does the runtime system know that the function is "done" and should be evaluated?
Qi keeps stock of the arity of every function defined to it through a
hash table, so it knows when it is 'done' and when a partial
application is needed. If a function is not defined through Qi, then
no such check is made and the default Lisp application is used. This
is the default for all non-partial applications even using Qi-defined
functions.
The upshot of this is that you can talk to Lisp and use *all* the
Lisp features in Qi ing optional arguments and keywords and they will
work. You just cannot typecheck them as they stand.
(139-) (element? 1)
#<CLOSURE :LAMBDA [X234] [element? X233 X234]>
(140-) (MEMBER 1 [1 2 3] :TEST EQ)
[1 2 3]
(141-) (MEMBER [1] [[1] 2 3] :TEST EQ)
[]
Here I switch on the ype checker
(142-) (tc +)
true
(143+) (element? 1)
#<CLOSURE :LAMBDA [X237] [element? X236 X237]> : ((list number) -->
boolean)
(144+) (MEMBER [1] [[1] 2 3] :TEST EQ)
error: type error
Complete access to all of Lisp was part of the Good Solution in the
C21 Lisp manifesto and hence part of Qi.
4. The <Good Solution> keeps the good things of Lisp. You can write
functions in S-expression syntax and you have full communication with
the underlying Lisp.
Mark
Mark Tarver wrote:
> Complete access to all of Lisp was part of the Good Solution in the
> C21 Lisp manifesto and hence part of Qi.
>
> 4. The <Good Solution> keeps the good things of Lisp. You can write
> functions in S-expression syntax and you have full communication with
> the underlying Lisp.
This sounds indeed good. Thanks a lot for the explanation!
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Mark Tarver wrote:
> On 4 May, 14:03, Pascal Costanza <····@p-cos.net> wrote:
>> Does this mesh well with optional, rest and keyword arguments?
>
> In short no - currying does not mesh with optional, rest and keyword
> arguments as used in Lisp and you cannot really use the simply typed
> lambda calculus with that approach.
On a related note, OCaml has had optional and labelled arguments in the
presence of currying for some time.
The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop wrote:
> Mark Tarver wrote:
>> On 4 May, 14:03, Pascal Costanza <····@p-cos.net> wrote:
>>> Does this mesh well with optional, rest and keyword arguments?
>> In short no - currying does not mesh with optional, rest and keyword
>> arguments as used in Lisp and you cannot really use the simply typed
>> lambda calculus with that approach.
>
> On a related note, OCaml has had optional and labelled arguments in the
> presence of currying for some time.
So does OCaml know when a function call is "done"?
> The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
No, that's not equivalent.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
> > The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
>
> No, that's not equivalent.
It seems to me that it's precisely equivalent. How is it not
equivalent?
--
Chris Smith
Chris Smith wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>>> The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
>> No, that's not equivalent.
>
> It seems to me that it's precisely equivalent. How is it not
> equivalent?
In one case, I have to say (foo (list 1 2 3)), in the other I can simply
say (foo 1 2 3).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
> Chris Smith wrote:
> > Pascal Costanza <··@p-cos.net> wrote:
> >>> The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
> >> No, that's not equivalent.
> >
> > It seems to me that it's precisely equivalent. How is it not
> > equivalent?
>
> In one case, I have to say (foo (list 1 2 3)), in the other I can simply
> say (foo 1 2 3).
Somehow I doubt that's the most significant syntactic change necessary
to convert Lisp code into OCaml.
--
Chris Smith
Chris Smith wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>> Chris Smith wrote:
>>> Pascal Costanza <··@p-cos.net> wrote:
>>>>> The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
>>>> No, that's not equivalent.
>>> It seems to me that it's precisely equivalent. How is it not
>>> equivalent?
>> In one case, I have to say (foo (list 1 2 3)), in the other I can simply
>> say (foo 1 2 3).
>
> Somehow I doubt that's the most significant syntactic change necessary
> to convert Lisp code into OCaml.
:-D
Sure, but there is a convenience issue involved.
Assume you have developed a binary operator. It's natural to express it
as a two-argument function:
(defun foo (x y) ...) ;; Common Lisp
(define (foo x y) ...) ;; Scheme
Later on you realize that it is better to turn this into a function for
an arbitrary number of arguments. You can simply change the definition
like this:
(defun foo (&rest args) ...) ;; Common Lisp
(define (foo . args) ...) ;; Scheme
There is no need to change any of the already existing call sites.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> wrote:
> Assume you have developed a binary operator. It's natural to express it
> as a two-argument function:
>
> (defun foo (x y) ...) ;; Common Lisp
> (define (foo x y) ...) ;; Scheme
>
> Later on you realize that it is better to turn this into a function for
> an arbitrary number of arguments.
I suppose this is a matter of perspective. I would tend to think that,
instead of it being better to convert it into an operator on a lit, that
it would be better to define a new operator that generalizes it:
fooAll = foldr foo foozero
where foozero is the identity of the operator foo (okay, I'm writing
Haskell rather than ML; but the same would work there if I weren't too
lazy to look up what folds are like in ML). If foo doesn't have an
identity, then this would be a cue to me to wonder whether generalizing
to a list makes any sense at all. I would then start asking questions
about what this operator should do with an empty list, for example.
> You can simply change the definition like this:
>
> (defun foo (&rest args) ...) ;; Common Lisp
> (define (foo . args) ...) ;; Scheme
>
> There is no need to change any of the already existing call sites.
Indeed, but neither is there a need to change the existing call sites
simply because you defined a fold. You'd just keep using the original
operator.
--
Chris Smith
Pascal Costanza wrote:
> (defun foo (&rest args) ...) ;; Common Lisp
> (define (foo . args) ...) ;; Scheme
>
> There is no need to change any of the already existing call sites.
There is a converse "convenience issue" from the OCaml:
let f x y = x+y
f 2 3
to the Lisp:
(defvar f (lambda (x) (lambda (y) (+ x y))))
(funcall (funcall f 2) 3)
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop wrote:
> Pascal Costanza wrote:
>> (defun foo (&rest args) ...) ;; Common Lisp
>> (define (foo . args) ...) ;; Scheme
>>
>> There is no need to change any of the already existing call sites.
>
> There is a converse "convenience issue" from the OCaml:
>
> let f x y = x+y
> f 2 3
>
> to the Lisp:
>
> (defvar f (lambda (x) (lambda (y) (+ x y))))
> (funcall (funcall f 2) 3)
+ You don't write code like that in Common Lisp. You would rather write
it like this:
(defun f (x)
(lambda (y) (+ x y)))
+ If you really want to store functions in global variables via defvar
(very unlikely), you should better stick to the naming conventions in
Common Lisp and use the name *f*, but that's only a side remark.
+ If you want to avoid having to say funcall on variables, you can
define your own variable-defining macro:
(defmacro define (name definition)
(let ((global (gensym)))
`(progn
(defvar ,global ,definition)
(define-symbol-macro ,name ,global)
(defmacro ,name (&rest args)
`(funcall ,',global ,@args))
',name)))
No need to blame the language for missing a construct.
+ None of this applies to Scheme. In Scheme, you can just say this:
(define f (lambda (x) (lambda (y) (+ x y))))
((f 2) 3)
There are situations in which multiple namespaces are more convenient,
though.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Jon Harrop wrote:
>> let f x y = x+y
>> f 2 3
>
> + You don't write code like that in Common Lisp. You would rather write
> it like this:
>
> (defun f (x)
> (lambda (y) (+ x y)))
Regardless, it is still more obfuscated than the OCaml and requires you
to "alter all call sites".
> + If you really want to store functions in global variables via defvar
> (very unlikely), you should better stick to the naming conventions in
> Common Lisp and use the name *f*, but that's only a side remark.
Sure. Then you have the confusion of needing funcall for the first but not
the second application of "f".
> + If you want to avoid having to say funcall on variables, you can
> define your own variable-defining macro:
>
> (defmacro define (name definition)
> (let ((global (gensym)))
> `(progn
> (defvar ,global ,definition)
> (define-symbol-macro ,name ,global)
> (defmacro ,name (&rest args)
> `(funcall ,',global ,@args))
> ',name)))
>
> No need to blame the language for missing a construct.
You had to add the construct yourself => blame the language for a missing
construct.
> + None of this applies to Scheme. In Scheme, you can just say this:
>
> (define f (lambda (x) (lambda (y) (+ x y))))
>
> ((f 2) 3)
The definition is still longer, more obfuscated and equally inflexible.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Pascal Costanza wrote:
> Ah, the joy of an extensible programming language:
Greenspun.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Pascal Costanza wrote:
> Chris Smith wrote:
>> Pascal Costanza <··@p-cos.net> wrote:
>>>> The OCaml equivalent of Lisp's "rest" is to accept a list, of course.
>>> No, that's not equivalent.
>>
>> It seems to me that it's precisely equivalent. How is it not
>> equivalent?
>
> In one case, I have to say (foo (list 1 2 3)), in the other I can simply
> say (foo 1 2 3).
Your translation to Lisp is incorrect. Lisp cannot distinguish between these
two OCaml implementations because it lacks static typing:
let add (x, y) = x+y;;
let add [x; y] = x+y;;
For these purposes, a tuple (such as the pair in the first case) is simply a
list that is statically guaranteed to have two elements.
So the Lisp equivalent to both of these definitions is:
(defun foo (x y) (+ x y))
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop wrote:
> Pascal Costanza wrote:
>> In one case, I have to say (foo (list 1 2 3)), in the other I can simply
>> say (foo 1 2 3).
> Your translation to Lisp is incorrect. Lisp cannot distinguish between these
> two OCaml implementations because it lacks static typing:
> let add (x, y) = x+y;;
> let add [x; y] = x+y;;
> For these purposes, a tuple (such as the pair in the first case) is simply a
> list that is statically guaranteed to have two elements.
> So the Lisp equivalent to both of these definitions is:
> (defun foo (x y) (+ x y))
What in the world are you talking about? Optional parameters are
extensions of the parameter list, not type-specific substitutes.
Your examples have nothing to do with the topic.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> What in the world are you talking about? Optional parameters are
> extensions of the parameter list, not type-specific substitutes.
> Your examples have nothing to do with the topic.
You snipped the context, which is Lisp's "rest" arguments and not optional
arguments.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
> Dan Bensen wrote:
>> What in the world are you talking about? Optional parameters are
>> extensions of the parameter list, not type-specific substitutes.
Jon Harrop wrote:
> You snipped the context, which is Lisp's "rest" arguments
> and not optional arguments.
But Pascal was talking about precisely the situation
where &rest is used for optional arguments:
>>>> The OCaml equivalent of Lisp's "rest" is to accept a list
>>> No, that's not equivalent.
>> It seems to me that it's precisely equivalent.
> In one case, I have to say (foo (list 1 2 3)),
> in the other I can simply say (foo 1 2 3).
&rest is one of the few Lisp constructions that invisibly
change the structure of data. The &rest parameter is a list
that's constructed automatically from bare arguments.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> &rest is one of the few Lisp constructions that invisibly
> change the structure of data. The &rest parameter is a list
> that's constructed automatically from bare arguments.
The equivalent of which is passing values in a list in OCaml.
OCaml also has statically-typed optional arguments, that were discussed
elsewhere in this thread.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
In article <···············@mid.individual.net>, Pascal Costanza wrote:
> Jon Harrop wrote:
>>
>> On a related note, OCaml has had optional and labelled arguments in the
>> presence of currying for some time.
>
> So does OCaml know when a function call is "done"?
When you partially some keyword arguments, you get a new function that
needs fewer keyword arguments:
# let foo ~a ~b = a + b
val foo : a:int -> b:int -> int = <fun>
# let f = foo ~b:6
val f : a:int -> int = <fun>
# let x = f ~a:5
val x : int = 11
So you're "done" when you don't have any more arguments to supply.
--
Neel R. Krishnaswami
·····@cs.cmu.edu
Frederic Beal wrote:
> On 2007-05-07, Jon Harrop <···@ffconsultancy.com> wrote:
>> Except Lisp always passed by list so both cases are (foo 1 2 3) in Lisp
>> (but not in other languages).
>
> With all due respect, what you say would be a bit daft.
Then you've misunderstood what I said.
> Lisp is perfectly able to tell the difference between
> (foo 1 2 3) and (foo (list 1 2 3)) and (foo (list 1) (list 2 3)).
> In the first case, the _list_ of arguments contains _three_ items,
> which are numbers, in the second case, the _list_ of arguments contains
> _one_ argument, which is a list (which contains _three_ numbers), and
> in the third case, etc.
Exactly. So a translation of this:
* (defun tail (head &rest tail) tail)
* (tail 1 2 3)
(2 3)
into OCaml/F# is:
# let tail (head::tail) = tail;;
# tail [1; 2; 3];;
- : int list = [2; 3]
>> I'd rather abstractions that are forced upon me didn't make reading
>> the "n"th function argument O(n).
>
> It does not.
Given a (linked) list of arguments, what is the complexity of getting
the "n"th argument? When does this apply in Lisp?
> You have misconceptions about how Lisp works (and I say
> that, even though I prefer Haskell now, but for REAL reasons).
Perhaps, but I have yet to hear a decent answer to the above question.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Mark Tarver wrote:
> On 4 May, 14:03, Pascal Costanza <····@p-cos.net> wrote:
>
>> Does this mesh well with optional, rest and keyword arguments?
>
> In short no - currying does not mesh with optional, rest and keyword
> arguments as used in Lisp and you cannot really use the simply typed
> lambda calculus with that approach [...]
Btw, somewhere I have library that allows me to write things like this:
cl-u> (defun foo (a b c &key the-key) (list a b c the-key))
cl-u> (foo 1 _ 3 4 :the-key _)
cl-u> (funcall * 2 5)
==> (1 2 3 4 5)
.
On 6 May, 13:56, "Szymon \"tichy\"" <···········@o2.pl> wrote:
> Mark Tarver wrote:
> > On 4 May, 14:03, Pascal Costanza <····@p-cos.net> wrote:
>
> >> Does this mesh well with optional, rest and keyword arguments?
>
> > In short no - currying does not mesh with optional, rest and keyword
> > arguments as used in Lisp and you cannot really use the simply typed
> > lambda calculus with that approach [...]
>
> Btw, somewhere I have library that allows me to write things like this:
>
> cl-u> (defun foo (a b c &key the-key) (list a b c the-key))
>
> cl-u> (foo 1 _ 3 4 :the-key _)
>
> cl-u> (funcall * 2 5)
>
> ==> (1 2 3 4 5)
>
> .
OK. Thats neat - but thats only the beginning ....
The proper handling of polyadic functions, especially in Lisp, is a
tricky business if you approach the matter from the point of view of
designing a type theory. The design of the type theory is as important
as the currying bit because really the currying is about making the
language lambda calculus consistent so that it fits onto the simply
typed lambda calculus.
_______________________________________________________________
Def: from Qi wiki
A functional language is lambda calculus consistent if it supports
currying and the treatment of applications as first class objects in
the manner of the lambda calculus. The latter requires that an
application can itself be applied like any other function if that
application returns a function as a value.
Qi in this sense is lambda calculus consistent. Common Lisp is not
since currying is not supported, nor does Common Lisp permit
expressions such as ((identity '+) 3 4) where identity is the identity
function (CL requires FUNCALL to be used - (FUNCALL (identity '+) 3
4).
Qi is lambda calculus consistent.
The advantages of lambda calculus consistency is that it promotes the
uniformity of the treatment of expressions and permits the use of a
type theory based on the simply typed lambda calculus (STLC). Since
most modern statically typed functional programming languages
incorporate this type theory as a proper part, lambda calculus
consistency makes for a standard and well-understood type theory.
________________________________________________________________
What are the options?
1. Ban polyadic functions altogether.
I don't like this because it violates condition 4. of the <good
solution> in the L21
(Lisp for the 21st century) project.
2. Allow polyadic functions but (on the whole) leave them out of the
type theory. This is what Qi does.
3. Bundle optional arguments into a non-optional list. Effectively
polyadic functions then disappear and harmony is restored. This is
what Qi/tk does with type checking TCL/tk (which is full of optional
commands to build widgets). This engenders a complex type theory but
is STLC consistent and you can have currying.
4. Write special rules for some polyadic functions. Qi does this for
functions like
output, error, do
and 2 or 3 more. output does what FORMAT T does (e.g. (output "~A
~A" Hello World) prints 'Hello World' and can take any number of
parameters. BUT 3 points.
a. This is done on a individual basis; each such function has its
own type rule. In contrast regular functions have their type stored
in a hash table which is much better for implementing very large
numbers of typed functions. Adding to a hash table produces no
depreciation in performance - special type rules do (even at Qi's 600
KLIPS enough rules can, eventually, slow things down).
b. 'output' is type theoretically very simple. A CL function like
WRITE for example has a large number of such options (about 11 I
think) which needs a fairly tough type theory.
c. In Qi output etc. are special forms - meaning that they cannot
be curried (it really makes no sense to curry 'output'). So Qi does
not curry them.
5. Get your compiler to do the completions for missing options.
This is an engineering solution. Get your compiler to fill in the
missing options by their defaults and impose a canonical ordering on
these defaults before the result is passed to the type checker. In
this case the system will obey STLC and to the observer will appear to
obey currying and allow default values and keywords etc. *This is I
think the best solution*; although it requires work I have not done.
6. Throw away STLC type theory and invent a special 'roll your own'
type theory which obeys Lisp rather than lambda calculus.
Mark
> 3. Bundle optional arguments into a non-optional list. Effectively
> polyadic functions then disappear and harmony is restored. This is
> what Qi/tk does with type checking TCL/tk (which is full of optional
> commands to build widgets). This engenders a complex type theory but
> is STLC consistent and you can have currying.
So how does this work?
Presumably this only allows partial currying, as optional arguments
are bundled together, and you can't curry them one after the other?
The work around I'd be tempted by is using a trailing character like
(+ 1 2 _) to indicate that currying is desired in the ambiguous cases,
and performing the type inference as you already do, by treating the
optional elements as a list.
Nameless wrote:
> Why should I keep on learning lisp when there are python and perl?
Lisp compilers are much more advanced, for one thing.
Xah Lee wrote:
> (if there is some demand, i will add a concrept, little programing
> example, that shows, how lisp's symbols and macros concepts, set it
> apart from new scripting languages)
I already did something similar, writing simple programs to simplify
symbolic expressions in different languages:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/239715
Also, here is a symbolic derivative example:
http://codecodex.com/wiki/index.php?title=Derivative
Note that pattern matching (as found in OCaml, F#, Haskell etc.) is very
useful for this kind of term rewriting and is not found in Python, Perl or
Lisp.
> This lisp's symbol concept, as far as i know, does not exist in some
> other high-level functional programing languages such as Haskell.
Correct.
> I'm
> not familiar with many functional languages except Lisp and
> Mathematica. I'm curious, as to how Haskell, which itself is quite
> with capable of symbolic computation i think, deals with it even
> though the language doesn't employ the concep of lisp's symbols per
> se.
In Standard ML, Haskell and F# you must define a sum type that represents a
symbolic expression whereas, in Lisp, you can use the built-in
s-expressions. The sum type that you define typically includes a "Symbol"
that carries its string name. For example, the F# code cited above used:
type expr =
| Int of int
| Add of expr * expr
| Mul of expr * expr
| Var of string with
static member ( + ) (f, g) = Add(f, g)
static member ( * ) (f, g) = Mul(f, g)
end
in this case, "Var" represents a symbol, e.g. the value Var "x" would
represent a variable x.
However, note that the best Lisp implementation of the symbolic simplifier
(by Pascal Constanza) avoids s-expressions, improving performance.
In OCaml, you can rely on the compiler inferring the sum type for you by
using polymorphic variants. However, this is not generally a good idea
because they are slower and harbor some of the disadvantages of dynamic
typing.
It is worth noting that eager, statically-typed languages like OCaml and F#
are many times faster than the other languages at this task. This is
precisely the forte of OCaml and F#, manipulating trees and graphs.
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
On May 4, 3:06 am, Jon Harrop <····@ffconsultancy.com> wrote:
>
> Lisp compilers are much more advanced, for one thing.
Though I hesitate to respond in this thread (and I didn't actually
read the rest of the article) there's actually a valid point here.
The last programming job I did involved doing some search stuff in
Python. I think Python had been chosen for almost (but actually not)
good reasons - people really wanted to use Lisp but it would have been
too hard (politically and technically), and the same people had recent
first-hand experience of some of the worse horrors of J2EE programming
so were negative about Java. Finally Python actually had the required
stuff (the ability to mmap files was critical to the proposed
technique for doing the search). (The reasons were actually not good
because Java could have done it as well, and if we'd had the courage
we could have done a POJO-style Java thing which would have been fine
and set a good example to other people, which as it was we failed
dismally to do. On the other hand they'd not have hired me - despite
the fact that even by then I didn't care about language choice with a
few exceptions (C++), I didn't look enough like a Java person (and
still don't of course).)
Anyway the experience of writing in Python was kind of interesting.
It had the usual single-implementation issues common to such things
which meant we depended on the right version (and I think a later
version than the one shipped with the OS since they'd decided to
change semantics in some quite major way at some point). But apart
from that writing programs that performed well (for us - we actually
had performance issues since we wanted to look at a lot of data)
turned out to be a matter of making sure that all the performance-
critical bits were done in libraries (in C) with Python merely a kind
of elaborate glue to get in the way. It was a bit like writing code
for an array processor or a DSP or something, except without any good
hardware reason for it. So one of the things I learned was "use a
language with a decent compiler"[*] I think.
--tim
[*] No glib comments about Java not having a decent compiler: actually
typical implementations do now (or did in 2004/5 and I bet they are
better now).
On May 4, 10:13 am, Tim Bradshaw <··········@tfeb.org> wrote:
> Anyway the experience of writing in Python was kind of interesting.
> [...] So one of the things I learned was "use a
> language with a decent compiler"[*] I think.
Bugger, I did not realise until too late that this was going to
comp.lang.python as well. I should therefore add a caveat: Use a
language with a high-performance (this is what I meant by "decent")
compiler if that kind of performance matters to you. It did to us,
but there are very many cases where it does not. In other words,
despite appearances I'm not particularly trying to slag off Python.
Jon Harrop wrote:
> It is worth noting that eager, statically-typed languages like OCaml and F#
> are many times faster than the other languages at this task. This is
> precisely the forte of OCaml and F#, manipulating trees and graphs.
Here is a page that sums up some important observations about
benchmarks: http://www.ccs.neu.edu/home/will/Twobit/bmcrock.temp.html
Especially:
- "With modern superscalar architectures, 5-level memory hierarchies,
and wide data paths, changing the alignment of instructions and data can
easily change the performance of a program by 20% or more, and Hans
Boehm has witnessed a spectacular 100% variation in user CPU time while
holding the executable file constant. Since much of this alignment is
determined by the linker, loader, and garbage collector, most individual
compiler optimizations are in the noise. To evaluate a compiler
properly, one must often look at the code that it generates, not the
timings."
- "The execution time of a program is often dominated by the time spent
in very small pieces of code. If an optimizing compiler happens to do a
particularly good job of optimizing these hot spots, then the program
will run quickly. If a compiler happens to do an unusually poor job of
optimizing one or more of these hot spots, then the program will run
slowly."
- "If the hot spots occur within library routines, then a compiler may
not affect the performance of the program very much. Its performance may
be determined by those library routines."
- "The performance of a benchmark, even if it is derived from a real
program, may not help to predict the performance of similar programs
that have different hot spots."
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Nameless wrote:
> Why should I keep on learning lisp when there are python and perl?
The more programing languages you know the better programer you will
be. Lisp can teach you a number of key things that are required to
be a good programmer in any of the P* lanuages.
On May 2, 6:20 pm, ······@gmail.com wrote:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
No you wouldn't. Lisp has a metric shipload of libraries. You can find
them at www.cliki.net.
On Wed, 02 May 2007 18:20:39 -0700, flifus wrote:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
see http://wiki.alu.org/The_Road_to_Lisp_Survey
--
Lars Rune Nøstdal
http://nostdal.org/
From: Ken Tilton
Subject: Re: Why stay with lisp when there are python and perl?
Date:
Message-ID: <hwo_h.345$wE1.296@newsfe12.lga>
Lars Rune Nøstdal wrote:
> On Wed, 02 May 2007 18:20:39 -0700, flifus wrote:
>
>
>>Python has readable syntax, a huge library, and bindings for what
>>seems like every major in linux. Perl has CPAN. It seems with those
>>languages if you want to do something all you have to do is import
>>functionality from a library someone had written and use that.
>>
>>In lisp you'd have to "roll your own".
>>
>>Why should I keep on learning lisp when there are python and perl?
>
>
> see http://wiki.alu.org/The_Road_to_Lisp_Survey
>
As a nappy-headed marketing ho, I like to recommend this specific link:
http://wiki.alu.org/RtL_Highlight_Film
Which page probably needs attention. Any recent surveyees not yet
highlighted?
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
From: Ken Tilton
Subject: Re: Why stay with lisp when there are python and perl?
Date:
Message-ID: <KAo_h.533$wE1.23@newsfe12.lga>
Lars Rune Nøstdal wrote:
> On Wed, 02 May 2007 18:20:39 -0700, flifus wrote:
>
>
>>Python has readable syntax, a huge library, and bindings for what
>>seems like every major in linux. Perl has CPAN. It seems with those
>>languages if you want to do something all you have to do is import
>>functionality from a library someone had written and use that.
>>
>>In lisp you'd have to "roll your own".
>>
>>Why should I keep on learning lisp when there are python and perl?
>
>
> see http://wiki.alu.org/The_Road_to_Lisp_Survey
>
Actually, think to come of it, the best response to this probable troll
would be to take them up on their claim of already learning Lisp and
indeed hit them with a couple of Qs from the survey:
Which Lisp are you learning?
How far have you gotten?
What languages were you using before, and what was worng with them?
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
······@gmail.com writes:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
>
I think if your asking that question, then probably the answer is that you
shouldn't. Lisp has a difficult to define quality that affects how you program
and how you think about problems. with python, perl, Java and C, I find the way
I program and even how I solve problems is substantially the same. With lisp,
it is different. The way I approach a task/problem, the expression of the
solution and the basic mental processes involved seem different and far more
rewarding. However, I think much of this is subjective and the experience isn't
the same for everyone. For example, you make reference to python having a
readable syntax as a positive, which implies you feel lisp doesn't. For me,
lisp has the simplist most straight-forward and easiest to read syntax of any
language I've ever used.
While its true that python, perl et. al., have a lot of pre-built libraries,
I'm not convinced this is always as advantageous as many claim. For example,
every perl programmer has gone through the tedious process of trying to work
out which of the 10 different libraries in CPAN that appear to do the same
thing is best. More than once I've been forced to re-factor my perl program
because there has been a version update, but the CPAN module I selected is no
longer being actively supported and has not been updated for the new version
and I've had to find an alternative module. At the same time, when I've needed
some functionality you would normally find in a perl/python library in lisp,
I've typically been able to implement that functionality myself in less time
than the time spent selecting which library/module to use and learning how it
works and I don't have the version upgrade problems.
I noticed the other day that I had 3 different versions of python installed on
my system. I decided to remove all but the latest version. However, I couldn't
as important python based programs I wanted depended on different versions of
python. While I'll admit that it is likely all these programs would work with
the latest version of the runtime, they have been built requiring specific
versions and unless I want to build them by hand and test them against a
specific version, I'm stuck with three different runtimes. I don't have this
issue with CL.
Finally, I've found that lisp has had the biggest influence on how I program
than any other language I've learnt. It has even affected my style of
programming in other languages and I think my perl, python and even Java code
is both more readable and maybe even more elegant as a result.
Different people appreciate different things in programming languages and a lot
comes down to personal taste. If your someone who feels that available
pre-built libraries and a familiar syntax are what is important, then lisp is
probably not for you. However, if your someone who likes to try out languages
which are substantially different or if your someone who finds there mental
processes fit with expressions in a lisp style or if your just someone who
likes to try different programming paradigms, then its probably worth the
effort. Likewise, if your main goal is ensuring you have the right skills for
your CV to get jobs, lisp is unlikely to be as beneficial as having more trendy
and/or buzz-word compliant languages. (although I can only think of one time
having lisp on my CV helped me get a job, I do think it helped indirectly
through its impact on my programming style. I've never been lucky enough to use
lisp in a production system, though I have used it often to prototype/refine my
solution or to experiment in the problem domain to gain better understanding
etc).
Tim
--
tcross (at) rapttech dot com dot au
······@gmail.com writes:
> Python has readable syntax, a huge library, and bindings for what
> seems like every major in linux. Perl has CPAN. It seems with those
> languages if you want to do something all you have to do is import
> functionality from a library someone had written and use that.
>
> In lisp you'd have to "roll your own".
>
> Why should I keep on learning lisp when there are python and perl?
Yes, because
http://xkcd.com/c224.html
Regards -- Markus