I've been using both Lisp & Perl for quite some time (lisp for 3 years,
perl for 2) and have been wondering why Perl is more popular (I work at
a company that mainly uses perl, though I think Lisp would be a better
solution). I am curious what the news-group's thoughts are on this.
-ted
--
··········@att.net
Ted Sandler wrote:
> I've been using both Lisp & Perl for quite some time (lisp for 3 years,
> perl for 2) and have been wondering why Perl is more popular (I work at
> a company that mainly uses perl, though I think Lisp would be a better
> solution). I am curious what the news-group's thoughts are on this.
> -ted
>
> --
> ··········@att.net
Here's some personal bias and snobbery:
[1] The American educational system is factoid-based (Memorize this,
memorize that...) and few people escape that sort of learning pattern.
Perl (and Java) exploit this kind of thing, rewarding the programmer who
can remember factoids better than the competition. Lisp, by contrast, has
a simple syntax and forces a person to almost immediately dig into the
hard stuff (recursion and macros and so on). LISP doesn't mesh well with
how we are taught (on average), and it takes patience and independence of
thought and a desire for elegance, as opposed to the "just get it done"
approach to life.
[2] When a programmer new to both languages is first given a task, it is
probably a small task. S/he can often pull some freebie perl from CPAN, or
grab the perl books' examples and cobble some working (if ugly) code
together quickly. This presents the programmer with a false economy:
"Well, if I got this done within the first hour of exposure to the
language, just imagine what I can do on a big project." Imagine, indeed,
since the perl solution just won't scale in terms of performance,
readability, multi-programmer interaction or just about any other thing I
might care about.
[3] I have noticed more machismo in programming than I did when I was in
engineering. There is often a "I am such a stud being able to <insert
false economy here>" attitude that we end up with reams of code that need
never have existed. Examples of "<insert false economy here>" include "do
my own memory management", "write my own base classes", "read unreadable
code", "read uncommented code", "prop up a poor architecture with layer on
layer of hacks", etc. etc. Perl appeals to at least a couple of those base
instincts, IMO.
So... perl presents an appealing false economy--it fits how most of us got
taught, rewards people with good memories for mere facts and appeals to
the macho in us. Perl isn't evil, nor are the people who like it (despite
my barbs), but the best I can say for it is that it's handy for small
stuff that noone else has to maintain. Unfortunately, since someone else
ALWAYS ends up maintaining it, that's just another false economy.
So okay, maybe perl is evil. ;)
<end rant>
Eric
>>>>> On Tue, 26 Jun 2001 05:12:39 GMT, Ted Sandler ("Ted") writes:
Ted> I've been using both Lisp & Perl for quite some time (lisp for 3 years,
Ted> perl for 2) and have been wondering why Perl is more popular (I work at
Ted> a company that mainly uses perl, though I think Lisp would be a better
Ted> solution). I am curious what the news-group's thoughts are on this.
What applications are Perl put to at your company?
SUMMARY
playing with Lisp operators is a snap:
(setq op '+)
(funcall op 2 2)
and associativity is a snap: just follow the parentheses.
TITLE
Lisp vs Perl Round One: Operator Associativity and Manipulation
BACKGROUND
In the process of converting a general pattern matcher (regular
expressions are pattern matchers limited to processing strings)
discussed in Peter Norvig's "Paradigms of Artificial Intelligence: Case
Studies in Common Lisp", I ran into a doosy. Something was a snap to do
in Lisp, but far from trivial in Perl. First the lisp code:
(defun match-if (pattern input bindings)
"Test an arbitrary expression involving variables. The pattern looks
like ((?if lisp-code) . rest)."
(and (progv (mapcar #'car bindings)
(mapcar #'cdr bindings)
(eval (second (first pattern))))
(pat-match (rest pattern) input bindings)))
What this code is doing is taking some lisp code and evaluating it
within a certain context. What is a context? A context is a set of
variable bindings. What the mapcar statement above is doing is setting
up a set of variable bindings so that when the lisp-code is evaluated,
it is evaluated in the context of those bindings. Then what happens is
the eval evauluates the lisp code with the variable bindings from the
context as a frame of reference.
The difficulty in converting this to Perl lies in the fact that
operators are not first class. Let's see an example of this lisp
pattern-matcher in action:
>> (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z)))
'(3 + 4 is 7))
>> ((?z . y) (?y . 4) (?x . 3))
What happened is that ?x got bound to 3, ?op got bound to + and ?z got
bound to 7 and then the pattern matcher called the if-block based on the
context formed by the earlier matches in the pattern.
Note how easily Lisp took an operator and stored it in a variable just
like anything else in Lisp. Second (though not the focus of this paper),
note how easy it was for the if block to receive and use a context. In
Perl, operators and contexts are not truly first class, meaning you
can't pass them around and you can't assign them to variables... easily.
They are in fact available to the Perl parser and a complicated set of
parsing modules, but such Herculean efforts appear ridiculous compared
to the expressive ease shown above.
In order for you to see firsthand what I am talking about with respect
to Perl, let's take a stab at writing that powerful little Lisp snippet
in Perl. First what would our pattern look like:
$pattern = [qw(X OP Y is Z),
'IF',
sub {$_[0]->{X} $_[0]->{OP} $_[0]->{Y} == $_[0]->{Z}} ];
$input = [ 3 '+' 4 is 7 ] ;
And here is our call to get the ball rolling:
pat_match ($pattern, $input, $bindings) ;
## And our desired output:
{ X => 3, Y => 4, Z => 7, OP => '+' }
sub match_if { my ($pattern, $input,$bindings) = @_ ;
$pattern->($bindings) ;
}
The above subroutine would work well, but it has a problem. There is no
way to assign the '+' to $_->{OP} ; Also, the actual if subroutine
reference must pander to Perl's complex associativity rules. In both
respects, Lisp is easier. As stated earlier playing with Lisp operators
is a snap:
(setq op '+)
(funcall op 2 2)
and associativity is a snap: just follow the parentheses.
The only way to handle a problem like this in Perl is to resort to
source filtering or parsing. And then you must make sure that your
minilanguage emulates the associativity semantics of Perl as well as
Perl in all respects...
From: John Clonts
Subject: Re: lisp & perl - operator associativity is simpler in Lisp (hence better)
Date:
Message-ID: <9hajbc01grs@enews2.newsguy.com>
Terrence Monroe Brannon <········@oracle.com> wrote in message
························@ap555sun.us.oracle.com...
> SUMMARY
> playing with Lisp operators is a snap:
>
> (setq op '+)
> (funcall op 2 2)
>
> and associativity is a snap: just follow the parentheses.
>
> TITLE
> Lisp vs Perl Round One: Operator Associativity and Manipulation
>
> BACKGROUND
> In the process of converting a general pattern matcher (regular
> expressions are pattern matchers limited to processing strings)
> discussed in Peter Norvig's "Paradigms of Artificial Intelligence:
Case
> Studies in Common Lisp", I ran into a doosy. Something was a snap to
do
> in Lisp, but far from trivial in Perl. First the lisp code:
>
> (defun match-if (pattern input bindings)
> "Test an arbitrary expression involving variables. The pattern looks
> like ((?if lisp-code) . rest)."
> (and (progv (mapcar #'car bindings)
> (mapcar #'cdr bindings)
> (eval (second (first pattern))))
> (pat-match (rest pattern) input bindings)))
>
> What this code is doing is taking some lisp code and evaluating it
> within a certain context. What is a context? A context is a set of
> variable bindings. What the mapcar statement above is doing is setting
> up a set of variable bindings so that when the lisp-code is evaluated,
> it is evaluated in the context of those bindings. Then what happens is
> the eval evauluates the lisp code with the variable bindings from the
> context as a frame of reference.
>
> The difficulty in converting this to Perl lies in the fact that
> operators are not first class. Let's see an example of this lisp
> pattern-matcher in action:
>
> >> (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z)))
> '(3 + 4 is 7))
>
> >> ((?z . y) (?y . 4) (?x . 3))
>
> What happened is that ?x got bound to 3, ?op got bound to + and ?z got
> bound to 7 and then the pattern matcher called the if-block based on
the
> context formed by the earlier matches in the pattern.
>
Aside from the point that you are making with respect to Perl, I am trying
to learn something from this very interesting example. Unfortunately there
must be some typos, and I-- a lowly application programmer untrained in the
depths of the CS/Lambda nature-- am not able to fill the gaps.
First I renamed the function to be consistent, I think:
(defun pat-match (pattern input bindings)
"Test an arbitrary expression involving variables. The pattern looks
like ((?if lisp-code) . rest)."
(and (progv (mapcar #'car bindings)
(mapcar #'cdr bindings)
(eval (second (first pattern))))
(pat-match (rest pattern) input bindings)))
Then I executed:
(pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z))) '(3 + 4
is 7))
But it complained
EVAL/APPLY: too few arguments given to PAT-MATCH
I also tried:
(pat-match '(?x ?op ?y is ?z) (?if (eql (?op ?x ?y) ?z)) '(3 + 4
is 7))
But it said:
EVAL: the function ?IF is undefined
I also tried these with various degrees of unsuccess:
(pat-match '(?x ?op ?y is ?z) '(?if (eql (?op ?x ?y) ?z)) '(3 + 4
is 7))
(pat-match '(?x ?op ?y is ?z) '(eql (?op ?x ?y) ?z) '(3 + 4 is
7))
(pat-match '(?x ?op ?y is ?z) (eql (?op ?x ?y) ?z) '(3 + 4 is
7))
Please reply, this is interesting but I'm not sure why....
Cheers,
John
From: Barry Margolin
Subject: Re: lisp & perl - operator associativity is simpler in Lisp (hence better)
Date:
Message-ID: <7b5_6.19$0v4.149@burlma1-snr2>
In article <···········@enews2.newsguy.com>,
John Clonts <·······@vvm.com> wrote:
>
>Terrence Monroe Brannon <········@oracle.com> wrote in message
>························@ap555sun.us.oracle.com...
>> SUMMARY
>> playing with Lisp operators is a snap:
>>
>> (setq op '+)
>> (funcall op 2 2)
>>
>> and associativity is a snap: just follow the parentheses.
>>
>> TITLE
>> Lisp vs Perl Round One: Operator Associativity and Manipulation
>>
>> BACKGROUND
>> In the process of converting a general pattern matcher (regular
>> expressions are pattern matchers limited to processing strings)
>> discussed in Peter Norvig's "Paradigms of Artificial Intelligence:
>Case
>> Studies in Common Lisp", I ran into a doosy. Something was a snap to
>do
>> in Lisp, but far from trivial in Perl. First the lisp code:
>>
>> (defun match-if (pattern input bindings)
>> "Test an arbitrary expression involving variables. The pattern looks
>> like ((?if lisp-code) . rest)."
>> (and (progv (mapcar #'car bindings)
>> (mapcar #'cdr bindings)
>> (eval (second (first pattern))))
>> (pat-match (rest pattern) input bindings)))
>>
>> What this code is doing is taking some lisp code and evaluating it
>> within a certain context. What is a context? A context is a set of
>> variable bindings. What the mapcar statement above is doing is setting
>> up a set of variable bindings so that when the lisp-code is evaluated,
>> it is evaluated in the context of those bindings. Then what happens is
>> the eval evauluates the lisp code with the variable bindings from the
>> context as a frame of reference.
>>
>> The difficulty in converting this to Perl lies in the fact that
>> operators are not first class. Let's see an example of this lisp
>> pattern-matcher in action:
>>
>> >> (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z)))
>> '(3 + 4 is 7))
>>
>> >> ((?z . y) (?y . 4) (?x . 3))
>>
>> What happened is that ?x got bound to 3, ?op got bound to + and ?z got
>> bound to 7 and then the pattern matcher called the if-block based on
>the
>> context formed by the earlier matches in the pattern.
>>
>
>Aside from the point that you are making with respect to Perl, I am trying
>to learn something from this very interesting example. Unfortunately there
>must be some typos, and I-- a lowly application programmer untrained in the
>depths of the CS/Lambda nature-- am not able to fill the gaps.
>
>First I renamed the function to be consistent, I think:
I'm not sure that MATCH-IF and PAT-MATCH are supposed to be the same
function. I think they call each other recursively.
It would probably help if you actually looked at the example in the Norvig
book. There seem to be some errors in the transcriptions in the message,
but I'll bet they're correct in the book.
> (defun pat-match (pattern input bindings)
> "Test an arbitrary expression involving variables. The pattern looks
> like ((?if lisp-code) . rest)."
> (and (progv (mapcar #'car bindings)
> (mapcar #'cdr bindings)
> (eval (second (first pattern))))
> (pat-match (rest pattern) input bindings)))
>
>Then I executed:
>
> (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z))) '(3 + 4
>is 7))
>
>But it complained
>
> EVAL/APPLY: too few arguments given to PAT-MATCH
PAT-MATCH takes 3 arguments, but you only gave it two. You're missing the
BINDINGS argument.
>I also tried:
>
> (pat-match '(?x ?op ?y is ?z) (?if (eql (?op ?x ?y) ?z)) '(3 + 4
>is 7))
>
>But it said:
>
> EVAL: the function ?IF is undefined
Now you gave it the third argument, but it sure doesn't look like
bindings. The bindings is supposed to be an alist.
>I also tried these with various degrees of unsuccess:
It doesn't look like you're making any attempt to understand how the code
is supposed to work and what the form of the arguments is supposed to be.
There's even a documentation string in the code that says what the pattern
should look like, but you're ignoring it.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: John Clonts
Subject: Re: lisp & perl - operator associativity is simpler in Lisp (hence better)
Date:
Message-ID: <9hapb301r9r@enews2.newsguy.com>
Barry Margolin <······@genuity.net> wrote in message
·····················@burlma1-snr2...
> In article <···········@enews2.newsguy.com>,
> John Clonts <·······@vvm.com> wrote:
> >
> >Terrence Monroe Brannon <········@oracle.com> wrote in message
> >························@ap555sun.us.oracle.com...
> >> SUMMARY
> >> playing with Lisp operators is a snap:
> >>
> >> (setq op '+)
> >> (funcall op 2 2)
> >>
> >> and associativity is a snap: just follow the parentheses.
> >>
> >> TITLE
> >> Lisp vs Perl Round One: Operator Associativity and Manipulation
> >>
> >> BACKGROUND
> >> In the process of converting a general pattern matcher (regular
> >> expressions are pattern matchers limited to processing strings)
> >> discussed in Peter Norvig's "Paradigms of Artificial Intelligence:
> >Case
> >> Studies in Common Lisp", I ran into a doosy. Something was a snap
to
> >do
> >> in Lisp, but far from trivial in Perl. First the lisp code:
> >>
> >> (defun match-if (pattern input bindings)
> >> "Test an arbitrary expression involving variables. The pattern
looks
> >> like ((?if lisp-code) . rest)."
> >> (and (progv (mapcar #'car bindings)
> >> (mapcar #'cdr bindings)
> >> (eval (second (first pattern))))
> >> (pat-match (rest pattern) input bindings)))
> >>
> >> What this code is doing is taking some lisp code and evaluating it
> >> within a certain context. What is a context? A context is a set of
> >> variable bindings. What the mapcar statement above is doing is
setting
> >> up a set of variable bindings so that when the lisp-code is
evaluated,
> >> it is evaluated in the context of those bindings. Then what happens
is
> >> the eval evauluates the lisp code with the variable bindings from
the
> >> context as a frame of reference.
> >>
> >> The difficulty in converting this to Perl lies in the fact that
> >> operators are not first class. Let's see an example of this lisp
> >> pattern-matcher in action:
> >>
> >> >> (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z)))
> >> '(3 + 4 is 7))
> >>
> >> >> ((?z . y) (?y . 4) (?x . 3))
> >>
> >> What happened is that ?x got bound to 3, ?op got bound to + and ?z
got
> >> bound to 7 and then the pattern matcher called the if-block based
on
> >the
> >> context formed by the earlier matches in the pattern.
> >>
> >
> >Aside from the point that you are making with respect to Perl, I am
trying
> >to learn something from this very interesting example. Unfortunately
there
> >must be some typos, and I-- a lowly application programmer untrained in
the
> >depths of the CS/Lambda nature-- am not able to fill the gaps.
> >
> >First I renamed the function to be consistent, I think:
>
> I'm not sure that MATCH-IF and PAT-MATCH are supposed to be the same
> function. I think they call each other recursively.
>
> It would probably help if you actually looked at the example in the Norvig
> book. There seem to be some errors in the transcriptions in the message,
> but I'll bet they're correct in the book.
Ok. Perhaps Mr. Brannon or other will chime in here about that, I don't own
the book.
>
> > (defun pat-match (pattern input bindings)
> > "Test an arbitrary expression involving variables. The pattern looks
> > like ((?if lisp-code) . rest)."
> > (and (progv (mapcar #'car bindings)
> > (mapcar #'cdr bindings)
> > (eval (second (first pattern))))
> > (pat-match (rest pattern) input bindings)))
> >
> >Then I executed:
> >
> > (pat-match '(?x ?op ?y is ?z (?if (eql (?op ?x ?y) ?z))) '(3 +
4
> >is 7))
> >
> >But it complained
> >
> > EVAL/APPLY: too few arguments given to PAT-MATCH
>
> PAT-MATCH takes 3 arguments, but you only gave it two. You're missing the
> BINDINGS argument.
Right. I was attempting to eval the supplied example. Can you tell me what
a well-formed example would look like? (Or perhaps Mr. Brannon will supply
a correction)
>
> >I also tried:
> >
> > (pat-match '(?x ?op ?y is ?z) (?if (eql (?op ?x ?y) ?z)) '(3 +
4
> >is 7))
> >
> >But it said:
> >
> > EVAL: the function ?IF is undefined
>
> Now you gave it the third argument, but it sure doesn't look like
> bindings. The bindings is supposed to be an alist.
>
> >I also tried these with various degrees of unsuccess:
>
> It doesn't look like you're making any attempt to understand how the code
> is supposed to work and what the form of the arguments is supposed to be.
> There's even a documentation string in the code that says what the pattern
> should look like, but you're ignoring it.
>
I thought that I might be able to learn from the example with y'alls help.
But if indeed there is another body of code behind MATCH-IF and/or ?IF then
I guess I'll have to wait until I can borrow or buy the book.
Thanks,
John
From: Thomas A. Russ
Subject: Re: lisp & perl - operator associativity is simpler in Lisp (hence better)
Date:
Message-ID: <ymik81ywxkx.fsf@sevak.isi.edu>
"John Clonts" <·······@vvm.com> writes:
> Barry Margolin <······@genuity.net> wrote in message
> > I'm not sure that MATCH-IF and PAT-MATCH are supposed to be the same
> > function. I think they call each other recursively.
> >
> > It would probably help if you actually looked at the example in the Norvig
> > book. There seem to be some errors in the transcriptions in the message,
> > but I'll bet they're correct in the book.
>
> Ok. Perhaps Mr. Brannon or other will chime in here about that, I don't own
> the book.
The code from the book is available on-line from Peter Norvig's web
site. Look at:
http://www.norvig.com/paip/
and in particular the link
http://www.norvig.com/paip/patmatch.lisp
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Doug Bagley
Subject: Re: lisp & perl - operator associativity is simpler in Lisp (hence better)
Date:
Message-ID: <m3hex2eu9u.fsf@ns.bagley.org>
Terrence Monroe Brannon <········@oracle.com> writes:
> The only way to handle a problem like this in Perl is to resort to
> source filtering or parsing.
Or use strings, eval and the regexp engine:
#!/usr/local/bin/perl
use strict; require v5.6.0;
my $input = "3 + 4 is 7";
my $pat = '?X ?OP ?Y is ?Z';
my $cond = '(?X ?OP ?Y) == ?Z';
my %map = ();
my $i = 1;
(my $re = $pat) =~ s/(\?\S+)/$map{$1}='$'.$i++,'(\S+)'/ge;
while (my($k,$v) = each %map) { $cond =~ s/\Q$k/$v/g; }
my $match = join(", ", map { "$_ => $map{$_}" } keys %map);
print eval qq{ \$input =~ /$re/; eval qq{$cond} ? "$match\n" : "failed\n" };
__END__
Output:
?OP => +, ?X => 3, ?Y => 4, ?Z => 7
Sorry, I just had to play devil's advocate. Forgive me if I fudged a
bit.
I won't argue that it's easier and cleaner and more efficient in Lisp.
Perl wasn't designed to do symbolic processing, so it shouldn't be
much of a surprise that it isn't real good at it.
Cheers,
Doug
From: Terrence Monroe Brannon
Subject: Re: lisp & perl - operator associativity is simpler in Lisp (hence better)
Date:
Message-ID: <yujqofr98tlp.fsf@ap555sun.us.oracle.com>
Doug Bagley <·························@bagley.org> writes:
: Terrence Monroe Brannon <········@oracle.com> writes:
: > The only way to handle a problem like this in Perl is to resort to
: > source filtering or parsing.
:
: Or use strings, eval and the regexp engine:
point conceded.
: I won't argue that it's easier and cleaner and more efficient in Lisp.
: Perl wasn't designed to do symbolic processing, so it shouldn't be
: much of a surprise that it isn't real good at it.
no, but thank you for your input.
Terrence Monroe Brannon <········@oracle.com> wrote in message news:<···················@ap555sun.us.oracle.com>...
> SUMMARY
> playing with Lisp operators is a snap:
>
> (setq op '+)
> (funcall op 2 2)
>
> and associativity is a snap: just follow the parentheses.
[...]
You are on your way to becoming a Schemer. :-) :-) :-)
(define op +)
(op 2 2)
:-)
g
Ted Sandler <··········@worldnet.att.net> writes:
> I've been using both Lisp & Perl for quite some time (lisp for 3 years,
> perl for 2) and have been wondering why Perl is more popular (I work at
> a company that mainly uses perl, though I think Lisp would be a better
> solution). I am curious what the news-group's thoughts are on this.
Perl look more like line noise. Therefore it's more likely that
purely random input is a valid program in perl. Since most
programming is a good approximation of the classic
monkeys-and-typewriters scenario, this explains why perl is more
popular: there simply are more valid perl programs of a given length
than Lisp ones.
What do you mean, you wanted a serious answer?
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Ted Sandler <··········@worldnet.att.net> writes:
>
> > I've been using both Lisp & Perl for quite some time (lisp for 3 years,
> > perl for 2) and have been wondering why Perl is more popular (I work at
> > a company that mainly uses perl, though I think Lisp would be a better
> > solution). I am curious what the news-group's thoughts are on this.
>
> Perl look more like line noise. Therefore it's more likely that
> purely random input is a valid program in perl. Since most
> programming is a good approximation of the classic
> monkeys-and-typewriters scenario, this explains why perl is more
> popular: there simply are more valid perl programs of a given length
> than Lisp ones.
>
> What do you mean, you wanted a serious answer?
Perl is very nice for searching through text files and for system
programming. If you want to get the job done quickly without writing
up your own tools or trying to integrate the work of many people into
another language, Perl is a very good choice.
Last time I looked into CL most didn't even have built in support for
sockets. Perl has sockets, IPC, and almost all the system calls for Unix.
--
Matthew.R.Wette at jpl.nasa.gov -- I speak for myself, not for JPL.
Matt Wette <···············@jpl.nasa.gov> writes:
> Last time I looked into CL most didn't even have built in support for
> sockets.
Could you please tell what is that CL that has no "built in" support
for sockets. It would be helpful also to tell what you mean by "built
in".
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Janis Dzerins <·····@latnet.lv> writes:
> Matt Wette <···············@jpl.nasa.gov> writes:
>
> > Last time I looked into CL most didn't even have built in support for
> > sockets.
>
> Could you please tell what is that CL that has no "built in" support
> for sockets. It would be helpful also to tell what you mean by "built
> in".
It's not defined in the language standard.
It does come pre-packaged in quite a number of implementations, but the
interface varies.
It's not so much of a problem that you should worry that you can't do
network programming in Lisp. But if you're going to port your resulting
product, you'd be well advised to get the spec on how sockets are done
in the other implementations you want to port to BEFORE you architect your
system to make sure you're not boxing yourself into a weird corner as you
proceed on whatever implementation you try first...
Kent M Pitman <······@world.std.com> writes:
> Janis Dzerins <·····@latnet.lv> writes:
>
> > Matt Wette <···············@jpl.nasa.gov> writes:
> >
> > > Last time I looked into CL most didn't even have built in support for
> > > sockets.
> >
> > Could you please tell what is that CL that has no "built in" support
> > for sockets. It would be helpful also to tell what you mean by "built
> > in".
>
> It's not defined in the language standard.
Yes, I know. I'm just wondering if that is what Matt meant.
> It does come pre-packaged in quite a number of implementations, but the
> interface varies.
And yes, we're talking about implementations here. And as far as I
know perl has only one implementation (with sockets and other stuff
mentioned). And hence the question -- which is the CL implementation
Matt was talking about.
> It's not so much of a problem that you should worry that you can't do
> network programming in Lisp. But if you're going to port your resulting
> product, you'd be well advised to get the spec on how sockets are done
> in the other implementations you want to port to BEFORE you architect your
> system to make sure you're not boxing yourself into a weird corner as you
> proceed on whatever implementation you try first...
In contrast to porting to different programming language when not
satisfied with the single Perl implementation.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>Therefore it's more likely that
>purely random input is a valid program in perl.
That is in fact true. See my 1999 paper on "Writing Perl Programs at Random":
http://perl.plover.com/idiocy/RandProg.html
>Since most programming is a good approximation of the classic
>monkeys-and-typewriters scenario, this explains why perl is more
>popular: there simply are more valid perl programs of a given length
>than Lisp ones.
That was exactly my conclusion.
--
@P=split//,·············@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
···@plover.com (Mark Jason Dominus) wrote in message news:<·················@news.op.net>...
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> >Therefore it's more likely that
> >purely random input is a valid program in perl.
>
> That is in fact true. See my 1999 paper on "Writing Perl Programs at Random":
>
> http://perl.plover.com/idiocy/RandProg.html
>
> >Since most programming is a good approximation of the classic
> >monkeys-and-typewriters scenario, this explains why perl is more
> >popular: there simply are more valid perl programs of a given length
> >than Lisp ones.
>
> That was exactly my conclusion.
That was a funny paper, but you seem mostly concerned with the
__DATA__ and __END__ Perl keywords, so if these 2 keywords were
eliminated, Perl would be "as correct as" Lisp? One could also say
that in a true infinite sample there are as many correct Perl as Lisp
programs (and this assertion would be just as meaningless).
You're going to get in trouble too by saying that XML is "the Lisp
way"! :-)
g
* theglauber wrote:
> That was a funny paper, but you seem mostly concerned with the
> __DATA__ and __END__ Perl keywords, so if these 2 keywords were
> eliminated, Perl would be "as correct as" Lisp? One could also say
> that in a true infinite sample there are as many correct Perl as Lisp
> programs (and this assertion would be just as meaningless).
I think in this case you have to do some kind of limit thing.
Clearly, in the limit the probability of a legal perl (- the stuff
above) or Lisp program is 0, but there may still be a well defined
value of $\lim_{n\rightarrow \infty}{P_l(n)\over P_p}$, and it may be
zero too.
--tim
I have a meta comment. It looks like similar questions are being asked more
frequently. Maybe a growing number of users are willing to evaluate Lisp as
an alternative to their current languages, and possibly also question their
current development practices.
On Tue, 26 Jun 2001 05:12:39 GMT, Ted Sandler <··········@worldnet.att.net>
wrote:
> I've been using both Lisp & Perl for quite some time (lisp for 3 years,
> perl for 2) and have been wondering why Perl is more popular (I work at
> a company that mainly uses perl, though I think Lisp would be a better
> solution). I am curious what the news-group's thoughts are on this.
The opinions of two well known Lisp experts, Richard Gabriel and Paul
Graham, provide some useful background material on the popularity of Lisp:
the "worse is better" saga
http://www.dreamsongs.com/WorseIsBetter.html
check the papers "Beating the Averages" and "Being Popular" ("Java's
Cover" may also be relevant)
http://www.paulgraham.com
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <·················@worldnet.att.net>,
Ted Sandler <··········@worldnet.att.net> wrote:
>I've been using both Lisp & Perl for quite some time (lisp for 3 years,
>perl for 2) and have been wondering why Perl is more popular (I work at
>a company that mainly uses perl, though I think Lisp would be a better
>solution). I am curious what the news-group's thoughts are on this.
Perl tends to be used for the kinds of things that were previously done
using either shell scripts or C programs. Its syntax borrows heavily from
both languages (and in the case of shell scripts, from some of the most
popular utilities that are used in them: grep, awk, and sed), so it's easy
for those programmers to switch to it. Since there was already a huge
community of C and shell programmers, Perl had a built-in user base with a
very short learning curve.
In other words, it filled a niche: It provides the best (and worst) of the
worlds of C and shell scripting. It was an easy sell to Unix sysadmins.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> wrote in message news:<··············@burlma1-snr2>...
[...]
> In other words, it filled a niche: It provides the best (and worst) of the
> worlds of C and shell scripting. It was an easy sell to Unix sysadmins.
Exactly!
One other good thing about Perl is that it provides a
programmer-friendly learning-curve from shell-scripting to C-style
programming to ... maybe Lisp. Perl supports a lot of the same
constructs that Lisp does, and nobody becomes a Perl "guru" without
learning to manipulate lists, write data-driven code, etc.
I tried learning Lisp on my own a couple of times before i succeeded.
Meanwhile i was getting very profficient with Perl. The third time i
tried to learn Lisp i had had enough exposure to Perl that Lisp
started making sense.
g
In article <····························@posting.google.com>,
glauber <··········@my-deja.com> wrote:
>One other good thing about Perl is that it provides a
>programmer-friendly learning-curve from shell-scripting to C-style
>programming to ... maybe Lisp. Perl supports a lot of the same
>constructs that Lisp does, and nobody becomes a Perl "guru" without
>learning to manipulate lists, write data-driven code, etc.
>
>I tried learning Lisp on my own a couple of times before i succeeded.
>Meanwhile i was getting very profficient with Perl. The third time i
>tried to learn Lisp i had had enough exposure to Perl that Lisp
>started making sense.
In fact, I'll bet you breathed a sigh of relief. Perl 4 didn't have
lists/arrays as true first-class objects. Perl 5 added this, but the
"reference" syntax that you have to use is extremely awkward and
counter-intuitive (IMHO). Then when you try to do the same things in Lisp
I hope you found it much easier, since you don't need all the \(...) and *
stuff to create references and automatically dereference things.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
>
> In article <····························@posting.google.com>,
> glauber <··········@my-deja.com> wrote:
> >One other good thing about Perl is that it provides a
> >programmer-friendly learning-curve from shell-scripting to C-style
> >programming to ... maybe Lisp. Perl supports a lot of the same
> >constructs that Lisp does, and nobody becomes a Perl "guru" without
> >learning to manipulate lists, write data-driven code, etc.
Excellent point!
> >I tried learning Lisp on my own a couple of times before i succeeded.
> >Meanwhile i was getting very profficient with Perl. The third time i
> >tried to learn Lisp i had had enough exposure to Perl that Lisp
> >started making sense.
Yes. I had a very similar experience.
> In fact, I'll bet you breathed a sigh of relief. Perl 4 didn't have
> lists/arrays as true first-class objects. Perl 5 added this, but the
> "reference" syntax that you have to use is extremely awkward and
> counter-intuitive (IMHO). Then when you try to do the same things in Lisp
> I hope you found it much easier, since you don't need all the \(...) and *
> stuff to create references and automatically dereference things.
In perl 6, the automatic list interpolation is going to be eradicated.
Therefore, lists of lists will be possible without explicit
referencing. Watch out lisp, Perl is intruding on your turf!
>
> --
> Barry Margolin, ······@genuity.net
> Genuity, Burlington, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
--
··········@att.net
Ted Sandler <··········@worldnet.att.net> wrote:
:> In fact, I'll bet you breathed a sigh of relief. Perl 4 didn't have
:> lists/arrays as true first-class objects. Perl 5 added this, but the
:> "reference" syntax that you have to use is extremely awkward and
:> counter-intuitive (IMHO). Then when you try to do the same things in Lisp
:> I hope you found it much easier, since you don't need all the \(...) and *
:> stuff to create references and automatically dereference things.
: In perl 6, the automatic list interpolation is going to be eradicated.
: Therefore, lists of lists will be possible without explicit
: referencing. Watch out lisp, Perl is intruding on your turf!
not really. PHP for example has this. and nobody would dare to compare PHP
with lisp, though it is list- and hash-wise better than perl. (no automatic
interpolation). in perl6 they finally fixed their memory management. but
stronger typing is still out of sight. so object method calls are still
slow, compilation slower than java's.
e.g. though JSP does its apache communication through sockets (same as
mod_lisp), it's still faster than mod_perl/mod_php4, which are apache in-proc.
strange but true. good chances for mod_lisp.
unfortunately i have to use PHP 4 for work now.
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq
I may be wrong but as far as i remember for building CMUCL you need some
perl scripts ..
--
Fritz Heinrichmeyer ··························@fernuni-hagen.de
FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany)
tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh
>>>>> "Fritz" == Fritz Heinrichmeyer <···················@fernuni-hagen.de> writes:
Fritz> I may be wrong but as far as i remember for building CMUCL you need some
Fritz> perl scripts ..
You may use perl to build CMUCL, but it is not a requirement.
I think the only requirements are: a C compiler and assembler, nm or
equivalent, and, finally, working CMUCL. :-)
Ray